Redis高可用集群实战：
map：JVM堆栈
redis：物理内存
之前的5种数据格式（String /hash/ list/ set/ sorted set（Zset）） + 地理位置信息查询等新的数据格式
范围查询：bitmap
地理空间：geospatial 索引半径查询
高级特性：
单副本：1个Redis服务端
多副本：主从模式
高可用：哨兵Sentinel、集群Cluster
没有太多的，做缓存使用
新浪微博：使用Redis量很高。点赞和评论很重要，只要不是大量的丢失就能够接受。
限制Redis性能：CPU、网络
单点故障：缓存击穿和缓存雪崩。
解决方法：数据备份。备份多少合理？比较安全的备份3份。主也算1+2=3.
2n+1=
拜占庭问题：实现最少资源的公平选举， 故障数据<存活的节点数据
选举的机制：2n+1.
多副本：
主主不支持备份，
解决方案：将从服务器在主挂掉之后，提升成主服务。（本身不能主动支持，要手动将从----变成主服务）
微博之前发生这种问题，临时性手动解决这种问题。
-------自动？
哨兵模式解决这种问题：
可靠性要求高的场景：分布式锁、
常见架构：
哨兵方式：
toC大多数是读多写少的场景。不能够写多。
主挂掉：立即进行选举。TCP/ip心跳实现检查。
服务直接连接哨兵的端口，
1、不用直接连接主Redis节点。
2、哨兵会帮服务找到主节点，并将该节点返回给服务端
3、服务端知道ip+端口
4、对主节点进行连接
哨兵能够监控多套数据集群。
哨兵模式的搭建：
Docker实现 ，
哨兵要进行选举。
redis查看当前节点的身份命令：info replication（把之前的主关机）
将之前的主进行开启，之后再进行开启，，这时的身份为从节点。
主从身份由哨兵进行管理，会竞争权限，当重新上线时如果有两台从节点，1<2 之前的节点会继续选举成为主节点，本例中的只有一台从节点，选举不会成功，。
集群方式：
进行改进，水平拓展，会修改很多的配置文件，slave数量从新进行改写。
如果不多的redis数据集群都挂掉，整个服务变得不可用。
同时，Redis占用的内存量很大，主写入1G的内存，从也会写入1G的内存数据，整个系统就会占用3G的内存（1主2从）
基于上述3种情况，这里使用集群分布的方式实现部署。
JedisCluster
1G的数据，key 根据hash槽 （0-16383个槽节点redi实例）下图1-6个槽，进行hash运算之后，得到1，之后只会将1G的数据写到对应的槽当中去，减少内存资源的损耗。（之前是1G* N个节点）
拓展，很容易实现。
通过JedisCluster进行读取数据，key（找到hash槽）----拿到数据
client不会到相应的master进行数据的拿取。
大型互联网公司的使用：
512
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
