@TOC
1.redis的cluster？
- 分散一台服务器的访问压力，将数据分散在不同的数据库服务器，实现负载均衡
- 分散一台服务器的存储压力
- 容易实现可扩展性
2.负载均衡算法
- CRC16：(了解) g(x)=1·x^8^+0·x^7^+0·x^6^+1·x^5^+1·x^4^+0·x^3^+0·x^2^ +0·x^1^+1·x^0^，即对应的二进制数为100110001； 每一位
- 轮询
- 加权轮询
- 随机
- hash（ip）
3.分布式Session
上面讲到了hash(ip)，这里就说一下，对于分布式来说，我们要保证分布式session的实现：
- hash(ip)：保证一台主机一直访问一台服务器
- 共享session：维护一个session服务器库，所有的服务器都从这里取
- 同步session：所有的服务器，只要一个修改，其他的都要同步。
4.redis cluster（重点来了）
客户段请求的key，经过CRC16得到一个值，然后对16384取余，来决定放置到哪个槽，每个节点负责一部分的槽,如：
两次寻址过程：
- 1 当前的节点通过crc16进行计算，如果是自己则进行执行
- 2 如果不是自己，返回错误Moved，然后告诉他哪个节点找
- 3 注意的是每个数据库会维护一部分槽slot，并且节点之间知道每个节点的slot的部分范围
-
5.补充，为什么槽的大小是16384，不是65536？
- 在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2 * 8 (8 bit) * 1024(1k) = 16K），也就是说使用2k的空间创建了16k的槽数。
- 虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) =65K），也就是说需要需要8k的心跳包， 作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。
综合来说：就是进行hash槽信息的同步的时候，保证发送的信息量少，并且一般不会超过1000个节点（一般不超过1000个也说明节点数不能太多，所以16384够用了！）
