A. java连接redis超时问题怎么解决
应该是redis本身的服务有问题了
本文所针对的连接超时问题所涉及的相关元素如下:
Redis客户端: Jedis (java)
Redis版本 :2.8.12
Redis部署操作系统类型:Linux
正文开始:
No 1.Redis执行大命令(时间复杂度为O(N)的命令)
问题剖析:
a.Redis服务器端通过单线程处理命令,一旦有大命令被执行,Redis将无法及时响应来自客户端的任何命令
关于Redis大命令的监控,可以查看slowlog来观察
b.在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a.尽量避免使用时间复杂度为O(N)的命令
b.如果无法避免使用时间复杂度为O(N)的命令,则应降低其使用频率,避免在业务高峰期时使用
No 2.Redis单次操作数据包过大
问题分析
a.单次操作数据包过大,且操作频繁,极有可能会导致网络拥堵
b.在使用jedis作为redis客户端时,当redis连接池的配置参数testOnBorrow=true时,默认会在获取redis连接
时,先执行redis的ping方法,而基于原因a,此时redis将无法及时响应,自然会报出time out异常
如何解决:
a.排查代码,确定是否存在大数据(数据条目过多/单条数据过大)操作,将其进行改造,改造方案有两个:
a1.数据拆分,变更数据类型(常见的情况是将java中的collection类型序列化后存入redis的String数据
类型中),如将String数据类型调整为hash/list/set等,这常用于解决单条数据量过大的情况
a2.调整业务逻辑,减少单次数据查询范围(常见的情况如将redis中的整个hash数据取回,在应用程序内存中获取需要的entry),如使用hget等单条查询命令替换hgetall命令
B. scala怎样创建redis集群连接池
此外，我还讨论过较为常见的基于服务器的数据存储，比如MongoDB和CouchDB。每个数据存储都有其优势和劣势，特别是当应用于特定领域时。本期的Java开发2.0关注的是Redis，一种轻量级键值对数据存储。多数NoSQL实现本质上都是键值对，但是Redis支持非常丰富的值集，其中包括字符串、列表、集以及散列。因此，Redis通常被称为数据结构服务器。Redis也以异常快速而闻名，这使得它成为某一特定类型使用案例的最优选择。当我们想要了解一种新事物时，将其同熟知的事物进行比较可能会有所帮助，因此，我们将通过对比其与memcached的相似性以开启Redis探索之旅。接着我们将介绍Redis的主要功能，这些功能可以使其在某些应用场景可以胜过memcached。最后我将向您展示如何将Redis作为一个传统数据存储用于模型对象。Redis和memcachedMemcached是一个众所周知的内存对象缓存系统，通过将目标键和值导入内存缓存运行。因此，Memcached能回避读取磁盘时发生的I/O成本问题。在Web应用程序和数据库之间粘贴memcached时会产生更好的读取性能。因此，对于那些需要快速数据查询的应用程序，Memcached是一个不错的选择。其中的一个例子为股票查询服务，需要另外访问数据库获取相对静态数据，如股票名称或价格信息。MemcacheDB将Redis与memcached相比较并不公平，它与MemcacheDB相比要好的多，MemcacheDB是一个分布式键值对存储系统，专为数据持久化而设计。MemcacheDB与Redis较为相似，其新增优势可以使其轻松地与memcached实现的客户端进行通信。但是memcached也有其局限性，其中一个事实就是它所有的值均是简单的字符串。Redis作为memcached的替代者，支持更加丰富的功能集。一些基准(benchmarks)也表明Redis的速度要比memcached快很多。Redis提供的丰富数据类型使其可以在内存中存储更为复杂的数据，这是使用memcached无法实现的。同memcached不一样，Redis可以持久化其数据。Redis解决了一个重大的缓存问题，而其丰富的功能集又为其找到了其他用途。由于Redis能够在磁盘上存储数据以及跨节点复制数据，因而可以作为数据仓库用于传统数据模式（也就是说，您可以使用Redis，就像使用RDBMS一样）。Redis还经常被用作队列系统。在本用例中，Redis是备份和工作队列持久化存储（利用Redis的列表类型）的基础。GitHub是以此种方法使用Redis的大规模基础架构示例准备好Redis，立即开始!要开始使用Redis，您需要访问它，可以通过本地安装或者托管供应商来实现访问。如果您使用的MAC，安装过程可能就不那么简单。如果您使用的是Windows??，您需要先安装Cygwin。如果您正在寻找一个托管供应商，Redis4You拥有一个免费计划。不管您以何种方式访问，您都能够根据本文下列示例进行操作，但是我需要指出的是，使用一个托管供应商进行缓存可能并不是很好的缓存解决方案，因为网络延迟可能会抵消任何性能优势。您需要通过命令与Redis进行交互，这就是说，这里没有SQL类查询语言。使用Redis工作非常类似于使用传统map数据结构，即所有的一切都拥有一个键和一个值，每个值都有多种与之关联的数据类型。每个数据类型都有其自己的命令集。例如，如果您计划使用简单数据类型，比如某种缓存模式，您可以使用命令set和get。您可以通过命令行shell与一个Reids实例进行交互。还有多个客户端实现，可以以编程方式与Redis进行交互。清单1展示了一个使用基础命令的简单命令行shell交互：清单1.使用基础的Redis命令redis127.0.0.1:6379>setpageregistrationOKredis127.0.0.1:6379>keys*1)"foo"2)"page"redis127.0.0.1:6379>getpage"registration"在这里，我通过set命令将键"page"与值"registration"相关联。接着，我发出keys命令（后缀*表示我想看到所有可用的实例键。keys命令显示有一个page值和一个foo，我可以通过get命令检索到与一个键关联的值。请记住，使用get检索到的值只能是一个字符串。如果一个键的值是一个列表，那么您必须使用一个特定列表的命令来检索列表元素。（注意，有可以查询值类型的命令）。Java与Jedis集成对于那些想要将Redis集成到Java应用程序的编程人员，Redis团队建议使用一个名为Jedis的项目，Jedis是一个轻量级库，可以将本地Redis命令映射到Java方法。例如Jedis可以获取并设置简单值，如清单2所示：清单2.Java代码中的基础Redis命令JedisPoolpool=newJedisPool(newJedisPoolConfig(),"localhost");Jedisjedis=pool.getResource();jedis.set("foo","bar");Stringfoobar=jedis.get("foo");assertfoobar.equals("bar");pool.returnResource(jedis);pool.destroy();在清单2中，我配置了一个连接池并捕获连接，（与您在典型JDBC场景中的操作非常相似）然后我在清单的底部设置了返回操作。在连接池逻辑之间，我设置了值"bar"和键"foo"，这是我通过get命令检索到的。与memcached类似，Redis允许您将过期（expiration）时间关联到一个值。因此我设置了这样一个值（比如，股票临时交易价格），最终将从Redis缓存中清除掉。如果我想在Jedis中设置一个过期时间，需要在发出set调用之后将其和一个过期时间关联。如清单3所示：清单3.Redis值可以设置为终止jedis.set("gone","daddy,gone");jedis.expire("gone",10);Stringthere=jedis.get("gone");assertthere.equals("daddy,gone");Thread.sleep(4500);StringnotThere=jedis.get("gone");assertnotThere==null;在清单3中，我使用了一个expire调用将"gone"的值设置为在10秒钟内终止。调用Thread.sleep之后，"gone"的get调用会返回null。Redis中的数据类型使用Redis数据类型，比如列表和散列需要专用命令用法。例如，我可以通过为键附加值来创建列表。
C. 供应链金融风控系统流程是怎样的
供应链金融风控系统流程是怎样的呢？依据我们供应链金融风控系统的开发经验，下面来为大家进行介绍。
前期准备
拿到足够多的数据做支撑
做足够灵活的分析平台去分析数据
产出风险事件进行阻拦风险
量化风险拦截的价值和不断分析案例进行策略优化
风控技术评估研究
日志选择：以增量日志方式记录存储，hadoop或spark做分析，集群同步到客户端机器上，做同步策略，不同纬度的数据做统计加工计算。
实时监控：监控在每一个环节的交易量和高风险操作，做阀值报警，以默认的规则做处理。
dns防范：防止http对dns的拦截，手动纪录中断被拦截掉的交易流，转向存储中心系统做处理给予用户提示。
报警提醒：在发生重大灾难的同时需要有一套完善的体系提醒风控人员近入作战，以短信或电话的形式发起通知给用户。
数据灾难：数据的历史纪录应该有完整的备库纪录，这种操作不是必须的但是必要的，防止管理员因为误操作导致的数据灾难不容小视，启东应急方案进行恢复。
日志选择：需要在原有基础上做集群数据分析后，统一有一个入口的分析平台做汇总，对不同维度的计算规则做排重，这里我们可以使用elk的方式把数据清洗完成后，做相关的分析调研，实时读库的方式不可取，增量数据库只保留历史的数据，可以对时间做相关的约定，查询的平台统一做相关的调控。
方案的选择和实施
针对现在的数据规则，需要对现有的各方数据做分析指标，做数据仓库，从不同的数据中计算对应的需要风控形成各种渠道的报表数据。如何通过查询海量的历史数据来支撑规则的运算，从分析的角度来看，又是一个IO密集型的应用；利用OLTP（online transaction processing ）和OLAP（online analytical processing）做相关的维度计算，主要针对用户、功能、数据片、存储空间、DB设计来做维度计算和方案的优化调整。
大到用hadoop做数据集群算法分析，也可以用spark、storm来做。
简而言之就是分布式框架，那么什么是分布式框架？
分布式计算框架实现了什么？简而言之，基于分布式计算框架的应用，就是一个分布式的应用；那么分布式的应用解决了什么问题？简而言之，就是将请求处理的业务逻辑和所需资源合理地分布到N台服务器上，这里就不在过多介绍。
基于C/S模式的原理，从client到server端的应用，采集需要的数据。Server之间通讯是有开销的，只不过这个开销是MS级的。系统在定位也是基于百万级的应用。
以分层的概念，针对每部的风控模块，需要在特定的时间做调整。缓存的应用：如果是历史级别的数据，可以采用redis、cache来做，防止减少对于I/O的读写操作，减少存储压力的开销。基于款时间的维度对应的风控系统计算，需要我们在处理的同时考虑数据的节点，分批次处理。对于变化多端的数据，建议利用高可用性能存储设计，基于DB设计即可，数据结构要基于范式(NF)设计，不可有冗余免得频繁返工。
数据分离的优先选择
数据库读写分离机制：在初期，风控系统一般都极为简单，此时侯一般通过数据库主从复制/读写分离/Sharding（或slave进行）等机制来保证交易系统的数据库和风控系统数据的同步及读写分离。风控系统对所需要的客户/账户数据、交易数据一般都只进行读操作。
缓存/内存数据库机制：不管是交易系统还是风控系统，高效的缓存系统是提升性能的大杀器，一般会把频繁使用的数据存放到Redis等缓存系统中。例如对风控系统，包括诸如风控规则、风控案例库、中间结果集、黑白名单、预处理结果等数据；对交易系统而言，包括诸如交易参数、计费模板、清结算规则、分润规则、银行路由策略等。对一些高频交易中，基于性能考虑，会采用内存数据库（一般会结合SSD硬盘）。
RPC/SOA架构：要降低交易系统和风控系统的耦合度，在初期系统服务较少的情况下，一般直接采用RabbitMQ/ActiveMQ之类的消息中间件或RPC方式来实现系统间服务的调用。如果系统服务较多，存在服务治理问题，会采用Dubbo之类的SOA中间件来实现系统服务调用，这个期间我们需要支持用异步消息完成rabbitMQ的消息的push/pull处理机制来处理违规数据和异常数据提取。
D. h2数据库和redis数据库最大的区别
nosql 处理 杂乱非结构化数据设计 比 中国页访问信息 楼说 阉割sql acid 特性 快啊 比插入数据 相反些 交易数据 数据安全稳定 压倒切候 rdbms 显现威力 rdbms 面nosql 些挑战 力优化 于些 非结构化数据支持 比json 数据 同rdbms 于 olap and oltp 支持 要比 nosql快点半点 总结 世界定东西 mongodb nosql 数据库吧 要用做稍微复杂几统计 家睡醒 再
E. Redis 秒杀系统的设计与实现
还记得刚工作那会，每每听到大牛们聊技术，各种专业术语，巴拉巴拉的，简直像是在听天书，比如什么中间件、分布式、SOA、无状态、热更新、懒加载、ACID、LVS、LDAP、VIP、CDN、负载均衡、鲁棒性、POJO、DSL、DI、IOC，太多太多了。一转眼快 10 年过去了，当很多新人再问到我这些名词的时候，我就在想，能不能用通俗易懂的大白话，就能聊明白这些专业的技术知识呢？
最近，给几个公司做技术咨询，经常会聊到秒杀系统。所以，借这次机会，尝试用大白话和大家聊聊 Redis 秒杀系统的设计与实现，。
说起 “秒杀”，我相信大家肯定都耳熟能详了，双十一零点抢购、手机整点抢购、抢火车票、1 元秒杀、抢红包等等，都可以说是秒杀的各种应用场景了。
秒杀系统的设计 ，难就难在，在极短的时间内，应对瞬时涌入平时成百上千倍的巨大流量，还包括各种攻击刷量作弊等未知流量，最终我们要保证在用户体验顺畅良好的情况下，不能多卖或者少卖。
而当我们公司决定要做秒杀系统的时候，我就去找业务，到时大概会有多少 UV，不知道 10 倍或者 100 倍？然后去找老板，给技术多少预算，最多平时的 10 倍不能再多了，当然越少越好，呵呵，也就是说让我们用平时最多 10 倍的预算去解决不可预估的用户流量，怎么做？要是有钱直接扔 1 万台服务器跑去吧，钱能解决的事就不是事，但问题是现在还没那么多钱，还要把事情搞定。
在聊秒杀系统设计之前，让我们先回到现实生活中，聊聊常见的“秒杀”场景和秒杀场景的独有特点，以及它们都是怎么应对的，在应对过程中都需要注意什么。
日常生活中，其实也有很多秒杀场景，比如，早上 9 点超市开门，老大爷老大妈抢购蔬菜水果，是不是？ 还有，新楼盘开盘抢购，是不是？ 股市开盘、交易所现场，是不是？
对的，生活中其实有太多类似场景了， 你有没有发现“秒杀”的独有特点呢？
记住了上面三个特点，我们就可以区分和确定秒杀的业务场景了。 这里我举一个特别的例子， 你说挤公交车，算不算秒杀场景呢？
下面，我再和大家聊一个关于抢猪肉的故事。
在保安部门充分讨论之后，保安大队长决定通过以下安排，在保证人员安全的前提下，还要做到相对公平。
后来，活动井然有序的开始了，但是由于猪肉销售场地太远，销售窗口又少，老大爷和老大妈们买肉又精挑细选，导致整个过程很漫长，而且外面等候的人们都开始骚动起来，这个时候保安大队长赶紧找到经理：
故事讲完了，如果我们把上面的故事，理解为秒杀业务场景，我们就可以总结出一个 秒杀系统的设计原则 了：
F. 风控系统实践之感: drools 和 redis
需求:
开发一个风控系统，系统包括, 规则引擎和计算引擎, 主要的内容如下:
1. 规则的增删改和实时生效, 规则的分类执行
2. 按照一定的纬度计算累计值，比如按照 IP, 用户 id, 账户 等纬度。
3. 需要支持滑动窗口，滚动窗口，长度窗口等
遇到的问题主要有以下几点:
1. redis 做流计算太过勉强，一是根据业务上的需求，需要统计的key 至少有几亿个，最多也有几十亿个，另外redis 中需要存储少量的交易的信息。估算下来量也是非常可观
2. redis 中 hot key 特别明显，比如按照商户的纬度去统计，如果不对商户的key 进行拆封，像盒马那种流量的商户，对redis 的压力是非常大的。
我们采用的是redis 的cluster 模式，这样的话redis hot key 对redis 影响会更大。对其进行拆分是非常必要的，比如 按照小时拆分。
3. 流式计算中，一个是乱序导致累加的计算不准确(有负值)，另外一个是消息延迟. 当时我们尝试使用flink 中的水印的概念去解决问题，发现并不适合。这个坑也是我们实践过后才发现的。
最痛苦的经历是乱序和延迟消息的解决，现在是采取纠正的方式解决。
规则引擎
规则引擎我们选用了drools，简单的探索了drools core, drools DRL, drools CEP 等，但是回头看看，针对drools的使用缺点还是很多, 而且很明显，暂时还没有替换的打算.
1. 使用 drools CEP 如何做分布式? 我们发现drools CEP中的几种窗口都是内存计算的，应用到分布式中就没有很好的办法，几乎做不到，除非drools 也去集成redis等这种分布式缓存。
2. 使用drools 觉得很笨重，因为依赖比较多，二是我们只用到了 drools 中的 if else 等判断，许多其它的功能基本就用不到，因为 1 中解决不了分布式的问题。所以从这点来说drools 已经废了，根本不用在创建kiesession 这种 重量级的东西。
3. drools中支持的运算符不是特别充分，比如像 log 运算，sum, max, avg 这种的运算等都是不支持的. DRL 语言对业务人员来说不是非常的友好。
4. 另外drools 中的 连续，非连续的规则，没有看出来如何配置，至少flink cep 是有这样API的。
综上所描述，不得不吐槽下 drools真是无语，也许了解的很简单，还有别的方式，另外drools workbench 也是很无语，很复杂，估计drools 厂商想通过这种方式挣钱。
总体感觉，如果有别的选择，最好不要选用drools，分布式的问题没有解决，就等于废了，因为各种分布式窗口都需要我们自己去实现。怎么办呢?
规则引擎最后还是采用了drools，根据具体的业务含义创建不同的kiesession, drools 起到了if else 判断的作用，至于滚动窗口，长度窗口和滑动窗口都通过redis来做计算。遇到头疼的问题，是
1. 根据不同的统计纬度，大概计算了下，需要几十亿个key，在redis 中做计算
2. 滑动窗口暂时靠 redis的zsort 的数据结构，性能不是非常好
3. 热点key 的问题，特别对于大商户的热点key 的问题，需要做拆分，拆分起来是比较复杂的
4. 消息延迟和消息乱序问题。
所以计算引擎的需求一般是
1. 计算很快，大几百个规则，能够很快的计算出准确的结果来
2. 计算准确率，当面对乱序和延迟消息的时候，如何计算的更加准确
3. 计算的量的问题，正如前面提到的，几十亿个key，另外还需要存储一些信息，计算的中间状态等，如何在redis 中丢失，就会造成计算不准确。
基于以上的问题，关键是如何做的更好，优化的更好，说实话，我没有找到答案，可以做的就是不断的优化redis 计算(暂时不能上大数据，比如flink， spark 等)，减少redis 的操作带来的网络开销。
其实最后还要提一下，如果能采用内存计算，不用分布式计算，会不会速度更快点，比如根据业务来做分片，这样在各个实例统计的中间值就不用汇总，那么每个实例只需要内存计算就好，不需要访问redis而带来的网络开销。但是这样做也会带来架构层面的调整，比如 如何做 fault tolerance， 如何做 状态持久化, 等一系列的问题。
从使用redis结果来看，效果也不是那么差，不考虑非常热点key 的情况下，最高tps 也达到6000多(2 台机器，16core，32G 内存), 一般公司的业务其实是可以满足的，对于非常热点的key，后续的优化是继续拆分.
一个好的风控系统是非常难的，做以笔记，以希望不断成长
G. loadrunner 怎么通过redis中间件发交易
1、接到项目时，首先了解系统架构，是B/S，还是C/S，使用什么应用服务器（即中间件），什么数据库？ 2、熟悉系统的功能、业务流程，明确项目的性能需求是什么？有哪些性能指标？ 3、编写性能测试计划。（有些公司不要求写）
H. java中如何构造ADT 数字货币
无论是股票交易系统，还是数字货币交易系统，都离不开撮合交易引擎，这是交易平台的心脏。同时，一个优秀的架构设计也会让交易平台的运维和持续开发更加容易。本文基于对开源项目的深入研究，总结了数字货币交易系统的架构设计。
关于撮合交易系统
撮合技术主要是从数据库撮合技术向内存撮合技术发展，这是因为数据库撮合技术越来越无法满足金融交易对于高可靠性、高性能、强安全性、可扩展性以及易维护性的需求。金融（币币）交易撮合系统中包括以下几个核心模块:
用户：终端用户委托报价与数量,生成订单发送至交易平台。
网关：负责收集用户订单,并将其派发给撮合引擎。
撮合引擎：交易系统中的核心部分,用于接收订单并根据业务逻辑实现订单 撮合同时生成交易记录,随后给予用户交易结果反馈。
数据库：用来存放交易过程中的订单和交易记录,实现数据持久化。
消息队列：一般用于订单消息的传输
关于技术选型
一个交易所平台的技术架构主要考虑安全性、分布式、易扩展、容错性、低延时、高并发等特性，以及熔断机制、服务注册和发现、消息服务、服务网关、安全认证、内存数据库、关系型数据库等各种选项，最终形成了如下技术选型：
分布式基础进行架构SpringCloud与Dubbo之间二选一，由于SpringCloud更加知名，SpringCloud的程序员更好招聘，有利于系统的长期运维升级，而且SpringCloud是基于SpringBoot开发，比较有亲切感，所以选择了SpringCloud, 其实由于阿里系的强大影响，国内Dubbo使用更加广泛，不同的团队可以根据自己的情况选择。
引入Hystrix断路器作为容错保护模块，防止单个服务的故障，耗尽整个撮合系统容器的线程资源，避免分布式环境里大量级联失败。对通过第三方客户端访问依赖服务出现失败、拒绝、超时或短路时执行回退逻辑。
采用Eureka作为服务注册与发现中心，实现中间层服务，以达到负载均衡和中间层服务故障转移的目的。
服务网关Spring Cloud Gateway 与 Zuul 的选型，选择了Zuul，因为名字短一些。
引入SpringCloud Security安全认证模块用于构建安全的应用程序和服务，SpringCloud Security在Spring Boot和Spring Security OAuth2的基础上，可以快速创建和实现常见的安全认证方式，如单点登录，令牌中继和令牌交换等。
引入Redis作为内存数据库，兼做系统数据缓存和内存计算。
使用MySQL作为关系数据库，性能测试非常过关，而且对熟悉MYSQL的程序员非常友好。
消息队列中间件MQ采用了Kafka, 具有超高性能体现。
I. redis最大多少个节点问题
转自 https://blog.csdn.net/chenxuegui1234/article/details/100171599
现在redis集群架构，redis cluster用的会比较多。
如下图所示
对于客户端请求的key，根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作！
那大家思考过，为什么有16384个槽么?
ps:CRC16算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。换句话说，值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536，而选择mod16384？
其实我当初第一次思考这个问题的时候，我心里是这么想的，作者应该是觉得16384就够了，然后我就开始查这方面资料。
很幸运的是，这个问题，作者是给出了回答的！
地址如下: https://github.com/antirez/redis/issues/2576
作者原版回答如下:
The reason is:
So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.
因此，能看懂上面那段话的读者。这篇文章不用看了，因为作者讲的很清楚了。本文只是对上面那段话做一些解释而已。
我们回忆一下Redis Cluster的工作原理！
这里要先将节点握手讲清楚。我们让两个redis节点之间进行通信的时候，需要在客户端执行下面一个命令
<pre style="box-sizing: border-box; outline: 0px; margin: 0px 0px 24px; padding: 8px; font-weight: 400; position: relative; white-space: pre-wrap; overflow-wrap: break-word; overflow-x: auto; font-family: Consolas, Inconsolata, Courier, monospace; font-size: 14px; line-height: 22px; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;">127.0.0.1:7000>cluster meet 127.0.0.1:7001
</pre>
如下图所示
意思很简单，让7000节点和7001节点知道彼此存在！
在握手成功后，两个节点之间会 定期 发送ping/pong消息，交换 数据信息 ，如下图所示。
在这里，我们需要关注三个重点。
到底在交换什么数据信息？
交换的数据信息，由消息体和消息头组成。
消息体无外乎是一些节点标识啊，IP啊，端口号啊，发送时间啊。这与本文关系不是太大，我不细说。
我们来看消息头，结构如下
注意看红框的内容，type表示消息类型。
另外，消息头里面有个myslots的char数组，长度为16383/8，这其实是一个bitmap,每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。
到底数据信息究竟多大？
在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。这块的大小是:
16384÷8÷1024=2kb
那在消息体中，会携带一定数量的其他节点信息用于交换。
那这个其他节点的信息，到底是几个节点的信息呢？
约为集群总节点数量的1/10，至少携带3个节点的信息。
这里的重点是: 节点数量越多，消息体内容越大。
消息体大小是10个节点的状态信息约1kb。
那定期的频率是什么样的？
redis集群内节点，每秒都在发ping消息。规律如下
因此，每秒单节点发出ping消息数量为
1+10*num（node.pong_received>cluster_node_timeout/2）
那大致带宽损耗如下所示，图片来自《Redis开发与运维》
讲完基础知识以后，我们可以来看作者的回答了。
(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。
当槽位为65536时，这块的大小是:
65536÷8÷1024=8kb
因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
(2)redis的集群主节点数量基本不可能超过1000个。
如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。
那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
(3)槽位越小，节点少的情况下，压缩率高
Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。
如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。
ps：文件压缩率指的是，文件压缩前后的大小比。
综上所述，作者决定取16384个槽，不多不少，刚刚好！