Redis服务支持5000万的QPS，有什么好的思路？

5000W QPS 量确实比较大，在当前的架构下，就以开源的redis cluster为例，假设每个节点跑8W QPS，那么也需要 5000/8 = 600+的节点，而Gossip在超过百级别节点的时候成本就越来越高，表现也越来越差了，所以用redis cluster来解这个问题不大靠谱，不靠谱的主要原因是Gossip的通信机制。
对于几个大厂来说，阿里云ApsaraDB for Redis/ApsaraCache用的是自研的集群方案（架构类似Codis），RedisLabs也是这个架构，AWS用的是开源的Redis Cluster，其他大厂就不清楚了。proxy+redis-server的架构可以做到线性的扩容，不用担心节点间的通讯压力，因为proxy做了分片，虽然也需要全局的Config Server/Zookeeper来维护数据分片信息，但是总体而言通信成本几乎为0，所以这种架构撑5000W QPS理论上是没有问题的。

这种架构还有一个优点就是可以把proxy当成一个中间件，在这个中间件上你可以做任何事情，比如可以把集群和主从的兼容性做到几乎一致、可以做无缝扩缩容、安全策略等等，redis cluster因为缺少了这么一个中间层就很难做这类事情（现在也有项目给redis cluster做一层proxy），当然因为带了proxy，带宽和CPU基本也是double的，对资源的消耗会大很多。

回到5000W这个问题上，理论上没问题不代表实际没问题，在几百个节点的集群中，由于节点数变多，fail的几率也大大变高；数据倾斜的问题也依然存在（访问热点导致的单个分片节点跑满，比如秒杀）；而且由于redis跑满时70-80%的cpu会消耗在内核网络栈上，所以当一个机器的CPU跑满时，cpu system和softirq会居高不下，对主机的稳定性是个巨大的挑战；另外对机房各个层次的交换机也会有巨大的挑战；总而言之，服务的SLA是很难得到满足的，为了保证SLA，可能需要上百台机器来部署几百个分片以分担5000W的压力，这个成本也不是一般小厂能承担的。而且节点数多的时候，对一些跨机指令是不友好的，比如mget，当节点数变多的时候会存在mget
hole的问题，延迟与单节点相比会是原来的1/2次方倍，比如9个节点，mget的延迟就是原来的3倍，100个节点，延迟就是原来的10倍，懂概率的同学可以自己算一下。

那到底如何彻底解决5000W这个问题呢，这里还是需要引入新技术的，比如智能网卡、用户态tcp/ip协议栈、多线程redis（减少分片数量，兼容性依然100%），纯用户态协议栈可以做到单机600W QPS（64 core）左右，用intel iWARP这个值可能能达到1500W QPS左右（把7层网络栈都offload到网卡），这样3-4台baremetal机器就能达到你说的要求；上层交换机也要用最新的机房建设标准，而且redis源码本身也要做很多的适配和重构；产品形态也要做相应改进，比如我们为了支持热key就做了读写分离这种产品形态。