美团怎么让Redis变得更厉害了，背后那些鲜为人知的故事

（引用来源：美团技术博客《美团Redis的演进与架构优化实践》等系列文章）

美团最早使用Redis的时候，跟很多公司一样，就是简单的单机版或者主从版，业务部门各自为战，需要就用，找个服务器搭起来，但随着美团业务像滚雪球一样越做越大，从外卖到打车，到酒店旅游，再到各种本地生活服务，Redis用的地方太多了，比如用户登录后的会话信息、外卖小哥的实时位置、优惠券的库存计数、搜索推荐的热点数据等等，几乎每个核心业务线都离不开它，原来的小打小闹根本撑不住这么大的场面,问题一个接一个地冒出来。

最头疼的问题就是容量和成本，美团的数据量太大了，一台服务器的内存根本装不下所有热点数据，他们试过当时流行的Codis这类集群方案，但用在美团这种极端复杂的场景下，还是有点力不从心，有的业务数据量可能就几个G，单独给它一整套集群太浪费；有的业务，像促销活动时，流量瞬间暴涨，需要能快速扩容，美团决定自己动手，搞一套更适合自己的Redis服务，他们管这个自研的系统叫“Cellar”。

Cellar的核心思想很有意思，它不像传统集群那样把数据固定分到几个大池子里，而是做得更细，它引入了一个“集群托管”的概念，你可以理解为一个大管家，这个大管家管理着底层成千上万台安装了Redis实例的物理服务器，这些服务器组成了一个巨大的资源池，当业务部门需要用到Redis时，不用关心机器在哪儿、内存多大，只需要向大管家申请一个“数据库实例”，大管家会从这个庞大的资源池里，智能地找一块合适的地方分配给你，可能是一台机器的一部分内存，也可能是好几台机器共同分担，这样就实现了资源的精细化管理，大大提高了机器的利用率,成本自然就降下来了。

另一个大问题是稳定性，Redis本身虽然快，但在美团的体量下，任何小概率事件都会变成频繁发生的事故，网络稍微抖动一下，主从同步可能就出问题，导致数据不一致，或者主机突然宕机，虽然能从机可以顶上来，但这个切换过程如果不够快，业务就会感觉到卡顿甚至失败，美团在Cellar里下了很多功夫来优化这些，他们改进了故障检测机制，让系统能更快、更准地判断一个节点是不是真的“挂了”，而不是因为网络波动被误判，他们优化了故障切换的流程，尽可能缩短不可服务的时间，让业务方几乎无感，他们还做了很多琐碎但至关重要的优化，比如针对美团外卖这种读写都极其频繁的场景，调整了Redis的底层参数，减少了不必要的内存分配和释放,让性能更稳定。

数据安全也是重中之重，美团有严格的数据可靠性要求，绝对不能丢数据，他们采用了多副本机制，一份数据会在不同的物理机上存好几个备份，备份不是简单的异步复制，他们增强了同步的可靠性，确保数据切实落盘了才算成功，他们还建立了完善的备份和恢复体系，定期给数据做快照并存到更便宜、更安全的对象存储上，万一出现极端情况,也能快速把数据恢复回来。

除了底层平台Cellar，美团在使用姿势上也积累了很多独特的经验，他们发现很多业务场景并不需要Redis提供的所有复杂命令，有时候只需要一个简单的增减操作，比如库存扣减，如果直接用Redis的命令，虽然功能强大，但网络传输和数据解析的成本有点高，他们开发了一种叫“缓存直通车”的架构，简单说，就是让业务应用直接与本地的缓存代理通信，这个代理会把很多简单的请求聚合起来，再批量与后端的Cellar集群交互，这样就极大地减少了网络往返次数，延迟更低，对后端集群的压力也更小，这套方案在像美团外卖“秒杀”这种瞬时超高并发的场景下,起到了关键作用。

美团让Redis变得更厉害，不是一个单点的技术突破，而是一个系统工程，它背后是自研Cellar集群管理平台来实现资源的精细化和低成本运营，是持续不断的稳定性优化来应对各种极端故障场景，是强化数据安全机制来保证可靠性，还有结合自身业务特点创新出的像“缓存直通车”这样的使用模式，这些点点滴滴的改进和积累，都是为了支撑美团每天亿级别的访问量和复杂多变的业务需求,是真正从实战中摸爬滚打出来的经验。