cache vs buffer
cache 缓存。经常使用的东西放在离自己更近的地方，比如cpu将最近使用的数据放入缓存中，提高存取速度。redis通常被当着缓存服务器使用。
buffer 缓冲。如泄洪湖/池时，将淡水湖作为泄洪时的缓冲地带，确保下游河道的流量平稳，降低风险。
Redis定位
Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存、消息队列等；
支持多种数据结构：String、Hash、List、Sorted List、Set等；
支持不同级别的持久化（RDB、AOF--redis1.1版本出现）；
通过哨兵（Sentinel）机制和集群（Cluter，3.0.2版本出现）机制提供高可用性
redis cluter
集群出现的目的在于：提高可扩展性，提高可用性
redis cluster的目标：
在1000个节点的时候仍能表现得很好并且可扩展性（scalability）是线性的。
没有合并操作，这样在 Redis 的数据模型中最典型的大数据值中也能有很好的表现。
写入安全（Write safety）：那些与大多数节点相连的客户端所做的写入操作，系统尝试全部都保存下来。不过公认的，还是会有小部分场景写入会丢失：（两个场景：主从之间异步复制、非强一致性保证）。
可用性（Availability）：在绝大多数的主节点（master node）是可达的，并且对于每一个不可达的主节点都至少有一个它的从节点（slave）可达的情况下，Redis 集群仍能进行分区（partitions）操作。
redis cluster为了获取更好的性能和扩展性，在可用性和一致性上做出了舍弃：Redis采取了P2P而非Proxy方式、异步复制、客户端重定向（节点间不需要传递command）
redis cluster的Availability允许少数节点出错，当某一主节点及其所有的从节点都挂掉的时候，cluster不可用（试配置而定），出现的概率其实不高。
redis cluster没有采用一致性hash算法（参考：五分钟理解一致性哈希算法(consistent hashing)），而是使用了固定数码的HASH_SOLT（hash槽），减少了复杂度，reshare就是完成HASH_SOLT和节点直接的映射关系变化。
自我理解：
1、redis cluster通过固定的HASH_SOLT，将key分散到不同的节点；
2、为提高可用性，每个master节点都可以有一个/多个slave节点，当master节点死掉后，其中的某个slave节点会通过选举算法升级为master节点，继续服务；
3、redis cluster还支持备份迁移，适用于某个master节点死掉后，再也无法回来的情况下，另外的master节点，会将其slave节点贡献出来，配给刚刚升级上来的master节点，作为slave节点；
4、redis cluster为了达到高性能和高扩展性，牺牲了部分可用性和数据一致性：各个master node之间不能互为备份，在少数情况下不能完全安全写入。
5、从redis cluster的设计思路中，可以发现：架构设计的关键在于搞清楚问题域，找到关键问题点，做好取舍。
参考资料：
示例：
考虑存储用户基本信息、绑定账户列表、社交信息、最近登录信息，分析下来，拟采用如下数据结构存储
用户基本信息 —— Hash
绑定账户列表 —— Set，账户信息详情使用String即可，毕竟更改账户信息场景的地方很少；
社交信息 —— Hash
最近登录信息 —— List，限定长度的列表表示，如果需要按照登录时间排序，则考虑使用Sorted List
使用redis做队列
redis提供Pub/Sub命令，提供消息发布/订阅 机制，使用List数据结构可以模拟队列，使用Sorted List可以模拟优先级的队列。
问题思考
1、redis什么场景下需要做持久化处理？
RE：作为缓存服务器使用时，可以不做持久化处理；作为数据存储服务器时，如果数据不容丢失且没有关系型数据库兜底，则需要做持久化处理。
作为缓存服务器时，不宜做持久化处理，缓存的数据可能被更改，在redis不可用期间，应用程序孩子继续修改数据，这时的修改并没有反应到redis缓存中，这时做持久化可能带来数据一致性问题。比如用户基本信息的缓存数据，不宜做持久化。
在redis当着存储服务器使用时，如果数据没有其他存储方式兜底，则需要做持久化。如用户最后登录时间，数据丢失一两次，影响不大，而且为了计算和存取速度，选择放在redis中，这时需要考虑持久化，丢一两次可以，但是不能全丢了。
2、redis cluster总的hash solt（哈希槽）的数量为什么是16384（2的14次方）？
RE：算法实现决定的。间redis官方网站解释，参考：cluster-spec
3、redis cluster 从节点升级为主节点的选举过程是不是一个paxos算法实现？
RE：不是。redis cluster的选举过程目标是：选举出唯一的一个从节点来代替已经FAIL掉的主节点。但是算法实现上和paxos上有一些相似之处：参加选举的原slave节点是proposaler，其他或者的master node是acceptor；
redis的使用场景案例
1、作为计数器使用
需要记录一个时间窗口期内某行为发生的次数，比如需要记录一天内用户登录失败次数，如果失败次数大于5次则锁定用户。可以这样做：用户每次登录失败，使用登录标识（手机号或者用户名）作为key，使用SET数据结构，将登录失败信息（时间戳、登录渠道）写入redis，过期时间设置为24小时；用户再次登录时，首先从redis查询该登录标识对应的登录失败记录是否超过了5次，如果没有则继续登录流程，否则报错。
由于redis记录自身天然过期，所以redis set记录写入后，无需再作更改，效率高效。
