此处我说的HTTP服务主要指如访问京东网站时我们看到的热门搜索、用户登录、实时价格、实时库存、服务支持、广告语等这种非Web页面，而是在Web页面中异步加载的相关数据。这些服务有个特点即访问量巨大、逻辑比较单一；但是如实时库存逻辑其实是非常复杂的。在京东这些服务每天有几亿十几亿的访问量，比如实时库存服务曾经在没有任何IP限流、DDos防御的情况被刷到600多万/分钟的访问量，而且能轻松应对。支撑如此大的访问量就需要考虑设计良好的架构，并很容易实现水平扩展。 # 架构 此处介绍下Nginx+JavaEE的架构。 ## 1. 单DB架构  早期架构可能就是Nginx直接upstream请求到后端Tomcat，扩容时基本是增加新的Tomcat实例，然后通过Nginx负载均衡upstream过去。此时数据库还不是瓶颈。当访问量到一定级别，数据库的压力就上来了，此处单纯的靠单个数据库可能扛不住了，此时可以通过数据库的读写分离或加缓存来实现。 ## 2. DB+Cache数据库读写分离架构  此时就通过使用如数据库读写分离或者Redis这种缓存来支撑更大的访问量。使用缓存这种架构会遇到的问题诸如缓存与数据库数据不同步造成数据不一致（一般设置过期时间），或者如Redis挂了，此时会直接命中数据库导致数据库压力过大；可以考虑Redis的主从或者一致性Hash 算法做分片的Redis集群；使用缓存这种架­构要求应用对数据的一致性要求不是很高；比如像下订单这种要落地的数据不适合用Redis存储，但是订单的读取可以使用缓存。 ## 3. Nginx+Lua+Local Redis+Mysql集群架构  首先Nginx通过Lua读取本机Redis缓存，如果不命中才回源到后端Tomcat集群；后端Tomcat集群再读取Mysql数据库。Redis都是安装到和Nginx同一台服务器，Nginx直接读本机可以减少网络延时。Redis通过主从方式同步数据，Redis主从一般采用树的方式实现：  在叶子节点可以做AOF持久化，保证在主Redis挂时能进行恢复；此处假设对Redis很依赖的话，可以考虑多主Redis架构，而不是单主，来防止单主挂了时数据的不一致和击穿到后端Tomcat集群。这种架构的缺点就是要求Redis实例数据量较小，如果单机内存不足以存储这么多数据，当然也可以通过如尾号为1的在A服务器，尾号为2的在B服务器这种方式实现；缺点也很明显，运维复杂、扩展性差。 ## 4. Nginx+Lua+ Redis集群+Mysql集群架构  和之前架构不同的点是此时我们使用一致性Hash算法实现Redis集群而不是读本机Redis，保证其中一台挂了，只有很少的数据会丢失，防止击穿到数据库。Redis集群分片可以使用Twemproxy；如果 Tomcat实例很多的话，此时就要考虑Redis和Mysql链接数问题，因为大部分Redis/Mysql客户端都是通过连接池实现，此时的链接数会成为瓶颈。一般方法是通过中间件来减少链接数。  Twemproxy与Redis之间通过单链接交互，并Twemproxy实现分片逻辑；这样我们可以水平扩展更多的Twemproxy来增加链接数。 此时的问题就是Twemproxy实例众多，应用维护配置困难；此时就需要在之上做负载均衡，比如通过LVS/HAProxy实现VIP（虚拟IP），可以做到切换对应用透明、故障自动转移；还可以通过实现内网DNS来做其负载均衡。  本文没有涉及Nginx之上是如何架构的，对于Nginx、Redis、Mysql等的负载均衡、资源的CDN化不是本文关注的点，有兴趣可以参考 [很早的Taobao CDN架构](http://www.docin.com/p-57729070.html) [Nginx/LVS/HAProxy负载均衡软件的优缺点详解](http://www.ha97.com/5646.html "Permalink to （总结）Nginx/LVS/HAProxy负载均衡软件的优缺点详解")