通过简单回顾阿里中间件 (Aliware) 消息引擎的发展史，本文开篇于双 11 消息引擎面临的低延迟挑战，通过经典的应用场景阐述可能会面临的问题 - 响应慢，雪崩，用户体验差，继而交易下跌。为了应对这些不可控的洪峰数据，中间件团队通过大量研究和实践，推出了低延迟高可用解决方案，在分布式存储领域具有一定的普适性。在此基础上，通过对现有有限资源的规划，又推出了分级的容量保障策略，通过限流、降级，甚至熔断技术，能够有效保障重点业务的高吞吐，成功的支撑集团包括海外业务平缓舒畅地度过双 11 高峰。与此同时，在一些对高可靠、高可用要求极为苛刻的场景下，中间件团队又重点推出了基于多副本机制的高可用解决方案，能够动态识别机器宕机、机房断网等灾难场景，自动实现主备切换。整个切换过程对用户透明，运维开发人员无需干预，极大地提升消息存储的可靠性以及整个集群的高可用性。

吞吐量：QPS， TPS，OPS 等等，并发。并不是越高越好，需要考虑 TP99。用户角度：系统是个黑盒，复杂系统中的任何一环到会导致稳定性问题。SLA：在某种吞吐量下能提供 TP99 为 n 毫秒的服务能力。降低延时，会提高吞吐量，但是延时的考核是 TP99 这样的稳定的延时。

解压后的安装 [root@server1 redis-3.0.5]# make 指定安装目录: [root@server1 redis-3.0.5]# make PREFIX=/usr/local/redis install进入/usr/local/redis里面: [root…