图4 “状态”的存储方式
明确了各个“状态”的存储方式后，我们就可以搭建出一套可快速扩容的系统：将系统中的应用服务设置为“无状态”，并注册到Eureka或ZooKeeper中。因为是“无状态”的服务，因此单个服务的宕机、重启等都不会影响到集群中的其他服务，并且很容易对应用服务进行横向扩展。另一方面，将带有数据的服务设置为“有状态”，并进行集群的“集中部署”（如MySQL集群），从而降低集群内部数据同步带来的延迟。
说明：“集中部署”是指尽可能的将相同或相关的数据、业务部署在同一机房中，利用内网提高数据的传输速度，尽量避免跨机房调用，如图5所示。
图5 多机房部署
在实际部署时，应该通过IP分组等方法尽量避免跨机房的数据传输、接口调用。并且使用DNS、Nginx等工具在某个机房整体故障时，将流量快速转接到其他机房。
最后要提醒大家的是，“无状态服务”虽然有很多的优势，但也不能盲目的将其作为唯一的选择。任何技术或架构的选择，都得看具体的业务场景，例如在小型项目或者仅有一个服务的项目中，就可以采用“有状态服务”来简化开发难度，缩短开发周期。
技术选型原则与数据库设计
在做技术选型时，既要注意待选技术的性能，也要考虑技术的安全性。并预估这些技术是否有足够长的生命力，项目组新成员是否能够快速掌握，而不能一味地追求技术的先进性。
这里以设计数据库为例，介绍一种数据库选型的思路。
以MySQL数据库为例，各种版本MySQL默认的并发连接数约为一二百，单机可配置的最大连接数为16384（一般情况下，由于计算机自身硬件的限制，单机实际能够负载的并发数最多为一千左右）。因此，高并发系统面临的最大性能瓶颈就是数据库。我们之前设计的各种缓存的目的，就是为了尽可能的减少对数据库的访问。
除了在页面、应用程序中增加缓存以外，我们还可以在应用程序和数据库之间加一层Redis高速缓存，从而提高数据的访问速度并且减少对数据库的访问次数，具体如下。
1.搭建高可用Redis集群，并通过主从同步进行数据备份、通过读写分离降低并发写操作的冲突、通过哨兵模式在Master挂掉之后选举新的Master；
2.搭建双Master的MySQL集群，并通过主从同步做数据备份；
3.通过MyCat对大容量的数据进行分库/分表，并控制MySQL的读写分离；
4.通过Haproxy搭建MyCat集群；
5.通过Keepalived搭建Haproxy集群，通过心跳机制防止单节点故障；并且Keepalived可以生成一个VIP，并用此VIP与Redis建立连接。
以上步骤如图6所示。
图6高性能高可用数据库架构
在实际进行数据库开发时，还需要合理使用索引技术以及适当设置数据库的各项性能参数，从而最大限度的优化数据访问操作。
缓存穿透与缓存雪崩问题
缓存可以在一定程度上缓解高并发造成的性能问题，但在一些特定场景下缓存自身也会带来一些问题，比较典型的就是缓存穿透与缓存雪崩问题。
注：为了讲解的方便，本文用MySQL代指所有的关系型数据库，用Redis代指所有数据库的缓存组件。
1.缓存穿透
缓存穿透是指大量查询一些数据库中不存在的数据，从而影响数据库的性能。例如Redis等KV存储结构的中间件可以作为MySQL等数据库的缓存组件，但如果某些数据没有被Redis缓存却被大量的查询，就会对MySQL带来巨大压力，如图7所示。
图7 缓存穿透
前面介绍过，单机MySQL最大能够承受的并发连接数只有一千左右，因此无论是设计失误（例如，某个高频访问的缓存对象过期）、恶意攻击（例如，频繁查询某个不存在的数据），还是偶然事件（例如，由于社会新闻导致某个热点的搜索量大增）等，都可能让MySQL遭受缓存穿透，从而宕机。
理解了缓存穿透的原因后，解决思路就已经明确了，举例如下。
（1）拦截非法的查询请求，仅将合理的请求发送给MySQL。如，可以使用验证码、IP限制等手段限制恶意攻击，并用敏感词过滤器等拦截不合理的非法查询。
（2）缓存空对象。如，假设在iphone9上市后，可能会导致大量用户搜索iphone9，但此时Redis和MySQL中还没有iphone9这个词。一种解决办法就是，将数据库中不存在的iphone9也缓存在Redis中，如Key=iphone9,value=””。之后，当用户再次搜索iphone9时，就可以直接从Redis中拿到结果，从而避免对MySQL的访问，如图8所示。
