基于Hash散列的数据缓存

Ⅰ 常用的缓存技术

第一章 常用的缓存技术
1、常见的两种缓存

本地缓存：不需要序列化，速度快，缓存的数量与大小受限于本机内存
分布式缓存：需要序列化，速度相较于本地缓存较慢，但是理论上缓存的数量与大小无限（因为缓存机器可以不断扩展）
2、本地缓存

Google guava cache：当下最好用的本地缓存
Ehcache：spring默认集成的一个缓存，以spring cache的底层缓存实现类形式去操作缓存的话，非常方便，但是欠缺灵活，如果想要灵活使用，还是要单独使用Ehcache
Oscache：最经典简单的页面缓存
3、分布式缓存

memcached：分布式缓存的标配
Redis：新一代的分布式缓存，有替代memcached的趋势
3.1、memcached

经典的一致性hash算法
基于slab的内存模型有效防止内存碎片的产生（但同时也需要估计好启动参数，否则会浪费很多的内存）
集群中机器之间互不通信（相较于Jboss cache等集群中机器之间的相互通信的缓存，速度更快<--因为少了同步更新缓存的开销，且更适合于大型分布式系统中使用）
使用方便（这一点是相较于Redis在构建客户端的时候而言的，尽管redis的使用也不困难）
很专一（专做缓存，这一点也是相较于Redis而言的）
3.2、Redis

可以存储复杂的数据结构（5种）
strings-->即简单的key-value，就是memcached可以存储的唯一的一种形式，接下来的四种是memcached不能直接存储的四种格式（当然理论上可以先将下面的一些数据结构中的东西封装成对象，然后存入memcached，但是不推荐将大对象存入memcached，因为memcached的单一value的最大存储为1M，可能即使采用了压缩算法也不够，即使够，可能存取的效率也不高，而redis的value最大为1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事实上底层是一个hashTable
sorted sets-->底层是一个skipList
有两种方式可以对缓存数据进行持久化
RDB
AOF
事件调度
发布订阅等
4、集成缓存

专指spring cache，spring cache自己继承了ehcache作为了缓存的实现类，我们也可以使用guava cache、memcached、redis自己来实现spring cache的底层。当然，spring cache可以根据实现类来将缓存存在本地还是存在远程机器上。

5、页面缓存

在使用jsp的时候，我们会将一些复杂的页面使用Oscache进行页面缓存，使用非常简单，就是几个标签的事儿；但是，现在一般的企业，前台都会使用velocity、freemaker这两种模板引擎，本身速度就已经很快了，页面缓存使用的也就很少了。

总结：

在实际生产中，我们通常会使用guava cache做本地缓存+redis做分布式缓存+spring cache就集成缓存（底层使用redis来实现）的形式
guava cache使用在更快的获取缓存数据，同时缓存的数据量并不大的情况
spring cache集成缓存是为了简单便捷的去使用缓存（以注解的方式即可），使用redis做其实现类是为了可以存更多的数据在机器上
redis缓存单独使用是为了弥补spring cache集成缓存的不灵活
就我个人而言，如果需要使用分布式缓存，那么首先redis是必选的，因为在实际开发中，我们会缓存各种各样的数据类型，在使用了redis的同时，memcached就完全可以舍弃了，但是现在还有很多公司在同时使用memcached和redis两种缓存。

Ⅱ 哈希（hash） - 哈希算法的应用

通过之前的学习，我们已经了解了哈希函数在散列表中的应用，哈希函数就是哈希算法的一个应用。那么在这里给出哈希的定义： 将任意长度的二进制值串映射为固定长度的二进制值串，这个映射规则就是哈希算法，得到的二进制值串就是哈希值 。
要设计一个好的哈希算法并不容易，它应该满足以下几点要求：

哈希算法的应用非常广泛，在这里就介绍七点应用：

有很多着名的哈希加密算法：MD5、SHA、DES...它们都是通过哈希进行加密的算法。
对于加密的哈希算法来说，有两点十分重要：一是很难根据哈希值反推导出原始数据；二是散列冲突的概率要很小。
当然，哈希算法不可能排除散列冲突的可能，这用数学中的 鸽巢原理 就可以很好解释。以MD5算法来说，得到的哈希值为一个 128 位的二进制数，它的数据容量最多为 2 ¹²⁸ bit，如果超过这个数据量，必然会出现散列冲突。
在加密解密领域没有绝对安全的算法，衫基一般来说，只要解密的计算量极其庞大，我们就可以认为这种加密方法是较为安全的。

假设我们有100万个图片，如果我们在图片中寻找某一个图片是非常耗时的，这是我们就可以使用哈希算法的原理为图片设置唯一标识。比如，我们可以从图片的二进制码串开头取100个字节，从中间取100个字节，从结尾取100个字节，然后将它们合并，并使用哈希算法计算得到一个哈希值，将其作为图片的唯一标识。
使用这个唯一标识判断图片是否在图库中，这可以减少甚多工作量。

在传输消息的过程中，我们担心通信数据被人篡改，这时就可以使用哈希函数进行数据校验。比如BT协议中就使用哈希栓发进行数据校验。

在散列表那一篇中我们就讲过散列函数的应用，相比于其它应用，散列函数对于散列算法冲突的要求低很多（我们可以通过开放寻址法或链表法解决冲突），同时散列函数对于散列算法是否能逆向解密也并不关心。
散列函数比较在意函数的执行效率，至于其它要求，在之前的我们已经讲过，就不再赘述了。

接下来的三个应用主要是在分布式系统中的应用

复杂均衡的算法很多，如何实现一个会话粘滞的负载均衡算法呢？也就是说，我们需要在同一个客户端上，在一次会话中的所有请求都路由到同一个服务器上。

最简单的办法是我们根据客户端的 IP 地址或会话 ID 创建一个映射关系。但是这样很浪费内存，客户端上线下线，服务器扩容等都会导致映射失效，维护成本很大。

借助哈希算法，我们可以很轻松的解决这些问题：对客户端的 IP 地址或会话 ID 计算哈希值，将取得的哈希值域服务器的列表的大小进行取模运算，最后得到的值就是被路由到的服务器的编号。

假设有一个非常大的日志文件，里面记录了用户的搜索关键词，我们想要快速统计出每个关键词被搜索的次数，该怎么做呢？

分析一下，这个问题有两个难点：一是搜索日志很大，没办法放到一台机器的内存中；二是如果用一台机器处理这么大的数据，处理时间会很长。

针对这两个难点，我们可以先对数据进行分片，然后使用多台机器处理，提高处理速度。具体思路：使用 n 台机器并行处理，从日志文件中读出每个搜索关键词，通过哈希局销函数计算哈希值，然后用 n 取模，最终得到的值就是被分配的机器编号。
这样，相同的关键词被分配到了相同的机器上，不同机器只要记录属于自己那部分的关键词的出现次数，最终合并不同机器上的结果即可。

针对这种海量数据的处理问题，我们都可以采用多机分布式处理。借助这种分片思路，可以突破单机内存桐塌游、CPU等资源的限制。

处理思路和上面出现的思路类似：对数据进行哈希运算，对机器数取模，最终将存储数据（可能是硬盘存储，或者是缓存分配）分配到不同的机器上。

你可以看一下上图，你会发现之前存储的数据在新的存储规则下全部失效，这种情况是灾难性的。面对这种情况，我们就需要使用一致性哈希算法。

哈希算法是应用非常广泛的算法，你可以回顾上面的七个应用感受一下。

其实在这里我想说的是一个思想： 用优势弥补不足 。
例如，在计算机中，数据的计算主要依赖 CPU ，数据的存储交换主要依赖内存。两者一起配合才能实现各种功能，而两者在性能上依然无法匹配，这种差距主要是： CPU运算性能对内存的要求远高于现在的内存能提供的性能。
也就是说，CPU运算很快，内存相对较慢，为了抹平这种差距，工程师们想了很多方法。在我看来，散列表的使用就是利用电脑的高计算性能（优势）去弥补内存速度（不足）的不足，你仔细思考散列表的执行过程，就会明白我的意思。

以上就是哈希的全部内容

Ⅲ 怎么实现redis的数据库的缓存(redis实现缓存的流程)

大致为两种措施：

一、脚本同步：

1、自己写脚本将数据库数据写入到redis/memcached。

2、这就涉及到实时数据变更的问题（mysqlrowbinlog的实时分析），binlog增量订阅Alibaba的canal，以及缓存层数据丢失/失效后的数据同步恢复问题。

二、纯贺业务层实现：

1、先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。

2、nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。

redis实现数据库缓存的分析：

对于变化频率非常快的数据来说，如果还选择传统的静态缓存方式（Memocached、FileSystem等）展示数据，可能在缓存的存取上会有很大的开销则裤差，并不能很好的满足需要，而Redis这样基于内存的NoSQL数据库，就非常适合担任实时数据的容器。

但是往往又有数据可靠性的需求，采用MySQL作为数据存储，不会因为内存问题而引起数据丢失，同时也可以利用关系数据库的特性实现很多功能。所以就会很自然的想到是否可以采用MySQL作为数据存孙皮储引擎，Redis则作为Cache。

MySQL到Redis数据复制方案，无论MySQL还是Redis，自身都带有数据同步的机制，比较常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog来实现的，这样的数据复制其实还是一个异步过程，只不过当服务器都在同一内网时，异步的延迟几乎可以忽略。那么理论上也可用同样方式，分析MySQL的binlog文件并将数据插入Redis。

因此这里选择了一种开发成本更加低廉的方式，借用已经比较成熟的MySQLUDF，将MySQL数据首先放入Gearman中，然后通过一个自己编写的PHPGearmanWorker，将数据同步到Redis。比分析binlog的方式增加了不少流程，但是实现成本更低，更容易操作。