高并发系统设计的 2 个要点，一定要看！-技术圈

高并发系统设计的 2 个要点，一定要看！

公众号程序猿DD

共 1973字，需浏览 4分钟

· 2020-08-04

点击上方蓝色“程序猿DD”，选择“设为星标”

回复“资源”获取独家整理的学习资料！

在系统设计时，如果能预先看到一些问题，并在设计层面提前解决，就会给后期的开发带来很大的便捷。

一、Session共享问题

单系统中的Session对象可以直接保存在内存中，但在分布式或集群环境下，多个不同的节点就要采取措施来共享Session对象，具体可以使用以下几种方式。

1.Session Replication

Session Replication 是指在客户端第一次发出请求后，处理该请求的服务端就会创建一个与之对应的Session对象，用于保存客户端的状态信息，之后为了让其他服务端也能保存一份此Session对象，就需要将此Session对象在各个服务端节点之间进行同步，如图1所示。

图1 Session Replication

2.Session Sticky

Session Sticky是通过Nginx等负载均衡工具对各个用户进行标记（例如对Cookie标记），使每个用户在经过负载均衡工具后都请求固定的服务节点，如图2所示。

图2 Session Sticky

3.独立Session服务器

可以将系统中所有的Session对象都存放到一个独立的Session服务中，之后各个应用服务再分别从这个Session服务中获取需要的Session对象，如图3所示。在大规模分布式系统中，就推荐使用这种独立Session服务方式。并且这种方式在存储Session对象时，既可以用数据库，也可以使用各种分布式或集群存储系统。

图3 独立Session服务器

二、缓存穿透与缓存雪崩问题

缓存可以在一定程度上缓解高并发造成的性能问题，但在一些特定场景下缓存自身也会带来一些问题，比较典型的就是缓存穿透与缓存雪崩问题。

1.缓存穿透

缓存穿透是指大量查询一些数据库中不存在的数据，从而影响数据库的性能。例如Redis等KV存储结构的中间件可以作为MySQL等数据库的缓存组件，但如果某些数据没有被Redis缓存却被大量的查询，就会对MySQL带来巨大压力，如图4所示。

图4 缓存穿透

理解了缓存穿透的原因后，解决思路就已经明确了，举例如下。

1）拦截非法的查询请求，仅将合理的请求发送给MySQL。

如，可以使用验证码、IP限制等手段限制恶意攻击，并用敏感词过滤器等拦截不合理的非法查询。

2）缓存空对象。

如，假设在iphone9上市后，可能会导致大量用户搜索iphone9，但此时Redis和MySQL中还没有iphone9这个词。将数据库中不存在的iphone9也缓存在Redis中，如Key=iphone9,value=””。之后当用户再次搜索iphone9时，就可以直接从Redis中拿到结果，从而避免对MySQL的访问，如图5所示。

图5缓存空对象

提示：为了减少Redis对大量空对象的缓存，可以适当减少空对象的过期时间。

3）建立数据标识仓库。

将MySQL中的所有数据的name值都映射成hash值，例如可以将“商品表”中的商品名“iphone8”映射成MD5计算出来的hash值，然后再将全部name的hash值放入Redis中，从而构建出一个“数据库中所有可查数据的hash仓库”。

之后，每次在查询MySQL之前都会先查询这个hash仓库，如果要查询数据的hash值存在于仓库中，再进入MySQL做真实的查询，如果不存在则直接返回。需要注意的是，由于不同数据的hash值在概率上时可能相同的，因此可能会漏掉对个别数据的拦截，如图6中的“B”。

图6 不同数据的Hash值相同而造成的问题

2.缓存雪崩

除了缓存穿透以外，在使用缓存时还需要考虑缓存雪崩的情况。缓存雪崩是指由于某种原因造成Redis突然失效，从而造成MySQL瞬间压力骤增，进而严重影响MySQL性能甚至造成MySQL服务宕机。

可参考使用以下解决方案：

1）搭建Redis集群，保证高可用；

2）避免大量缓存对象的key集中失效，尽力让过期时间分配均匀一些，例如，可以给各个缓存的过期时间乘一个随机数；

3）通过队列、锁机制等控制并发访问MySQL的线程数。

往期推荐

支付宝的架构到底有多牛逼？

Java 常用构建对象的三种方式

Spring Boot 中的 @EnableAutoConfiguration 是如何处理的？

为什么不建议把数据库部署在docker容器内？

BeanUtils 是用 Spring 的还是 Apache 的好？

扫一扫，关注我

一起学习，一起进步