此处我说的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化不是本文关注的点，有兴趣可以参考
实现
接下来我们来搭建一下第四种架构。
以获取如京东商品页广告词为例，如下图
假设京东有10亿商品，那么广告词极限情况是10亿；所以在设计时就要考虑：
1、数据量，数据更新是否频繁且更新量是否很大；
2、是K-V还是关系，是否需要批量获取，是否需要按照规则查询。
而对于本例，广告词更新量不会很大，每分钟可能在几万左右；而且是K-V的，其实适合使用关系存储；因为广告词是商家维护，因此后台查询需要知道这些商品是哪个商家的；而对于前台是不关心商家的，是KV存储，所以前台显示的可以放进如Redis中。 即存在两种设计：
1、所有数据存储到Mysql，然后热点数据加载到Redis；
2、关系存储到Mysql，而数据存储到如SSDB这种持久化KV存储中。
基本数据结构：商品ID、广告词、所属商家、开始时间、结束时间、是否有效。
后台逻辑
1、商家登录后台；
2、按照商家分页查询商家数据，此处要按照商品关键词或商品类目查询的话，需要走商品系统的搜索子系统，如通过Solr或elasticsearch实现搜索子系统；
3、进行广告词的增删改查；
4、增删改时可以直接更新Redis缓存或者只删除Redis缓存（第一次前台查询时写入缓存）；
前台逻辑
1、首先Nginx通过Lua查询Redis缓存；
2、查询不到的话回源到Tomcat，Tomcat读取数据库查询到数据，然后把最新的数据异步写入Redis（一般设置过期时间，如5分钟）；此处设计时要考虑假设Tomcat读取Mysql的极限值是多少，然后设计降级开关，如假设每秒回源达到100，则直接不查询Mysql而返回空的广告词来防止Tomcat应用雪崩。
为了简单，我们不进行后台的设计实现，只做前端的设计实现，此时数据结构我们简化为[商品ID、广告词]。另外有朋友可能看到了，可以直接把Tomcat部分干掉，通过Lua直接读取Mysql进行回源实现。为了完整性此处我们还是做回源到Tomcat的设计，因为如果逻辑比较复杂的话或一些限制（比如使用Java特有协议的RPC）还是通过Java去实现更方便一些。