槽道
redis-cluster槽道的原理:
本文配图是为了便于理解，如果图片影响了您的阅读，翻到博客末尾，笔者copy了无图版
1 redis服务如何判断key对应的槽道号,是否由本节点管理?
每一个节点都有一个属于自己的16384位的二进制位序列，每一位对应一个槽道号，当该二进制序列的某一位为1时，代表当前结点对该槽道号具有管理权。（下图表示，当前结点对槽道：0 2 3 4 .... 16383具有管理权：）
当客户端通过某一结点(比如8000)向cluster(集群)（下图表示一个集群，redis-cli的意思是登陆redis客户端：）
中set key value 时（该例中name为key，zhangsan为value）：
该结点就会通过hash取模算法将key值计算成某一个在[0,16383]区间内的值，这个值就是槽道号，这个时候当前结点拿着这个槽道号去自己的二进制序列中去比对，如果该槽道号对应的二进制序列中的那一位为1，则直接将该键值对存储到当前节点中，如果对应的二进制为0，见第二题答案
2 判断不归本节点管理时,获取正确的管理者信息"" class="has" height="225" src="https://img-blog.csdnimg.cn/20190105181655980.png" width="900" />
也就是说，当某一个结点收到 set key value 请求时，首先查看自己私有的二进制位序列，判断该key对应的槽道号是否归属自己管理，如果不归自己管理，则查看公有的大家都是一样内容的索引数组，根据槽道号找到找到该槽道号真正的管理者，并将信息转交给其真正的管理者进行保存。
————————————————————————————————————————————————————
无图版
槽道的原理:
1 redis服务如何判断key对应的槽道号,是否由本节点管理?
每一个节点都有一个属于自己的16384位的二进制位序列，每一位对应一个槽道号，当该二进制序列的某一位为1时，代表当前结点对该槽道号具有管理权。
当客户端通过某一结点(比如8000)向cluster(集群)中set key value 时（该例中name为key，zhangsan为value），该结点就会通过hash取模算法将key值计算成某一个在[0,16383]区间内的值，这个值就是槽道号，这个时候当前结点拿着这个槽道号去自己的二进制序列中去比对，如果该槽道号对应的二进制序列中的那一位为1，则直接将该键值对存储到当前节点中，如果对应的二进制为0，见第二题答案
2 判断不归本节点管理时,获取正确的管理者信息?
集群中的每一个节点不仅拥有一个属于自己的二进制位序列用来表示槽道号，而且还有一个公有的大家都一样的由16384个元素组成的索引数组，跟上面的字符数组一样，还是每一位对应一个槽道号，但是数组中存储的信息是该槽道号的实际管理者。
也就是说，当某一个结点收到 set key value 请求时，首先查看自己私有的二进制位序列，判断该key对应的槽道号是否归属自己管理，如果不归自己管理，则查看公有的大家都是一样内容的索引数组，根据槽道号找到找到该槽道号真正的管理者。
相关阅读
一、哈希表概述 首先简单介绍几个概念：哈希表（散列表）、映射、冲突、链地址、哈希函数。 哈希表（Hash table）的初衷是为了将数据映射
一、redis和memcache有什么区别？redis是现在的企业使用最广泛缓存技术，而在redis以前memcache是一些公司最常用的缓存技术，它们比较
cmd命令： start /wait vcredist_x86.exe /q /norestart start /wait vcredist_x64.exe /q /norestart start /wait dotNetFx40_
Redis Desktop Manager https://github.com/uglide/RedisDesktopManagerAnotherRedisDesktopManager https://github.com/qishibo
消息队列的实现方式有很多种，比如有专业的rabbitmq,rocketmq,kafka等，这些mq提供了非常专业的功能实现异步发送，而且这些接入又比较