前言
最近在看redis，有一些心得，为了不忘，现在记录下来。
我尝试从问题出发，步步递进，给大家较好的阅读体验，具体如下
- 什么是缓存，为啥要有它
- 缓存的实现方式-进程内的缓存
- 缓存的实现方式-进程级别的缓存
- redis作为一个进程级别的数据库，优点
- redis的高可用实现
什么是缓存，为啥要有它
一般我们将数据存储在数据库中，对于一些经常查询的业务，比如用户访问某一资源，通常我们会通过查询数据库查看用户是否有这个访问权限，这样业务的特点是查询频率高，查询数据库是比较重的操作，主要的耗时有数据库本身的查询耗时和网络耗时。如果将一些常使用的数据放在程序运行时内存里，随着程序的启动，加载数据库中信息到内存中，这样就减少了网络交互和数据库本身的查询耗时。
缓存的实现方式-进程内的缓存
这种就是在写程序时开辟一块内存，专门当做缓存供程序使用
优点
- 不需要网络传输。
- 不需要线程间切换。
- 缓存更新方便。因为是程序内的内存区域，我需要更新哪个区域，我可以直接定位到内存位置，并更新它。
缺点
- 拓展性差。还是一个商城的例子，用户想看自己的购物车，假设我们使用token进行状态保持，我解析token，抽取用户id，查看是否具有这个业务操作的权限。如果部署的程序只有一个，完全没问题。但是为了满足未来用户量高速增长，通过nginx横向拓展程序就可以有问题。假如我们平行的部署两个程序，用户来登录，程序a处理了这个请求，并将该用户的权限信息，token存在自己的内存区域，当该用户发起另外一个业务请求时，程序b接受这个请求，程序b拿到用户的token，抽取用户信息，查询自己的内存区域，发现没有这个用户信息，就判断这个用户没有访问权限。
- 如果是横向拓展的话，很有可能浪费内存。多个程序都有自己的内存区域，但是内存区域存的东西也是基本一样的。
缓存的实现方式-进程级别的缓存
优点
- 节约内存资源。
- 职责分离更明确
缺点
- 增加网络传输
- 增加线程间切换
- 单点，有风险
redis作为一个进程级别的数据库，优点
- 支持高可用部署
- 为了降低总体网络传输的延迟，提出了一个新思想：
假设我是新街口东方饺子王老板，提供送餐服务，我有2个快递员，假设我的饭是提前做好的
- 12：00，京师科技大厦小强定了一份饺子，快递员1去送餐，十分钟可以送到，再有十分钟回到饭店
- 12：02，京师科技大厦小红定了一份饺子，快递员2去送餐，十分钟可以送到，再有十分钟回到饭店
- 12：03，京师科技大厦小花定了一份饺子，没有快递员送餐：快递员1要到12:20才能回来，快递员2要到12：22才能回来。等待
- 12：04，京师科技大厦特朗普定了5份饺子，没有快递员送餐：快递员1要到12:20才能回来，快递员2要到12：22才能回来。等待
- 12：05，京师科技大厦克林顿定了5份饺子，没有快递员送餐：快递员1要到12:20才能回来，快递员2要到12：22才能回来。等待
- 12：20，快递员1接到小花订单，去送餐
- 12：22，快递员2接到特朗普订单，去送餐
假如特朗普和小强小红是一个公司的，特朗普心里就不爽了，都是同一时间定的，为啥他们到了，我的还没到？
那有什么解决方案吗 ？
- 减少每趟耗时。比如原来是快递员骑自行车，现在换成摩托车，原来是摩托车，现在换成汽车，原来汽车，现在换成火箭..
- 增加快递员的数量。 原来是2个，我就再招十来个 。
- 快递员每趟运送的货物争取多一点。比如上述例子，仅仅五分钟内，连续有京师科技大厦5单订单，一共13份饺子，假设一个快递员的后备箱可以装10分饺子，那在12：05的时候，快递员1 运送前四个订单，一共8份，快递员2运送第五个订单，一个5分。这样特朗普就和小强一起吃上饭了。
在计算机中 ，这三种解决方案分别对应的是
- 减少每趟耗时。往返时间：从发送方发送数据开始，直到发送方收到接收方回复的确认为止。数据传输的方式简单来说是这样的，先将数据转换为字节流，然后通过一个装置（调制解频器）转换为电磁波 ，通过网线或者无线电波传输，接收方接受到无线电波，将其转换成字节流，然后在转换成具体的可供程序使用的数据。是不是脑袋有点大，这个过程的优化可能不是软件工程师能做的。
- 吞吐量：单位时间内通过某个网络的数据量。这个优化可能不是软件工程师能做的。
- 对传输的数据进行缓冲，降低总体网络延迟。
第三种思想在很多地方都采用了，比如邮件服务器使用这种思想可以更快的下载新邮件，
redis 也是采用了第三种解决方案
感兴趣的同学可以参考官方文档
https://redis.io/topics/pipelining
redis的高可用实现
高可用的业务需求，当缓存服务因为某些原因不可用时，可以切换到另外一台机器的的缓存服务上。
可能涉及到的难点
- 我怎么判断缓存服务不可用
- 当不可用的时候，我怎么通知到所有使用缓存服务的客户端，现在你访问的这个有问题，你应该访问另外一个好的
- 备份的缓存服务存储的数据怎么和正在使用的缓存服务存储的数据保持一致
- 当我down掉的节点可以重新提供使用，怎么能加入到缓存，当做备胎使用
我尝试着对这几个问题提出自己的思考
1 我怎么判断缓存服务不可用
我需要知道每一个客户端使用缓存服务的情况，假如大家都说缓存有问题，那没问题，就换一个好的，如果至少有一半的客户都认为有问题，那这个缓存就有问题。像这样的事情肯定是谁用谁知道。哈哈
2 当缓存不可用的时候，我怎么通知到所有使用缓存服务的客户端，现在你访问的这个有问题，你应该访问另外一个好的
这个就要在程序部署的时候记录一下需要使用缓存服务的client，当要切换缓存时，我就逐一通知client就行
3 备份的缓存服务存储的数据怎么和正在使用的缓存服务存储的数据保持一致
这个其实很简单，把访问缓存的请求copy一份给备份的缓存就行。当然这个操作应该谁来做。如果是我的话，我就在client里来做，我做完一个操作，就把这个操作加到一个缓存队列中，让后台线程处理这个copy操作。
4 当我down掉的节点可以重新提供使用，怎么能加入到缓存，当做备胎使用
这个有两种方式，一种是down掉的缓存直接通知我，我活了，我想当备胎，你看怎么办。一种是 我每隔一段的时间对down掉的节点看一下，如果好了，我就将他允许他当备胎。
现在看看redis怎么做的
它提出了一种类型的人:哨兵，他的的职责如下
- 监控。他负责检查缓存和备胎的健康情况
- 通知。他监控出现异常的时候，可以通知管理员，或者其他程序。
- 自动故障恢复。当缓存不可以时，在备胎请求缓存的时候启动一个故障恢复的进程，当client使用缓存的时候就会被通知，你要换个备胎来用了。
- 配置提供者。client不能直接的访问缓存，需要先问一下这哥们我应该访问那个缓存。
针对上面的四个问题，看看redis是怎么做的
1 我怎么判断缓存服务不可用
他提出了一个阈值的概念 quorum ，当且仅当这两个条件满足时，才能确定一个缓存不可用
- 有几个哨兵同意当前缓存不可用
- 为了找到一个哨兵启动故障恢复的进程，哨兵们需要选举一个领导，由他来执行这个操作。
这个就有点坑爹了，如果是这样部署的缓存服务
- server001 master soilder01
- server002 replica1 soilder02
阈值设置的是1 ，当soilder02说 master不能使了，ok满足第一个条件，那第二个条件是找到一个哨兵来启动故障恢复程序，就剩一个soilder，还怎么选举，还需要选举吗？
当然这种情况可以认为的避免，比如可以将哨兵也可以安排在client里
- server001 master soilder01
- server002 replica1 soilder02
- server003 client1 soilder03
- server004 client2 soilder04
我把阈值设置为 1，就可以解决这个问题。
2 当缓存不可用的时候，我怎么通知到所有使用缓存服务的客户端，现在你访问的这个有问题，你应该访问另外一个好的
客户端通过哨兵来间接的访问缓存服务。这样做的弊端就是增加了一层网络消耗。本来我直接访问缓存拿到数据了，现在我需要问一下哨兵，现在的缓存地址是啥，我再根据这个地址访问缓存服务。
3 备份的缓存服务存储的数据怎么和正在使用的缓存服务存储的数据保持一致
当备胎和缓存master连上时，master负责备胎和自己保持一致性。
4 当我down掉的节点可以重新提供使用，怎么能加入到缓存，当做备胎使用
当备胎和缓存master连上时，master负责备胎和自己保持一致性。
