针对高并发系统的解决思路与方案

总体上：

开涛大神在博客中说过：在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

1.扩容

根据业务系统的类型，考虑不同的针对在数据库方面的扩容：

2.缓存（特别重要）

缓存设置的地方

手段

主要是Redis、CDN、浏览器等，其次可能一些问题

2.3可能存在的问题

2.3.1一致性

缓存一致性的话，主要可能考虑到以下几种可能导致一致性问题：

2.3.2缓存并发

由于并发时大量请求瞬间涌入，那么在建立或修改缓存时（还没完成），就可能已经打到DB或老缓存上了，造成雪崩或缓存一致性问题

解决方案：

锁机制

2.3.3缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案：

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

2.3.4雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案

大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

3.消息队列

做到了大量请求异步与解耦，比如下单与短信验证码请求的处理，及早返回处理。

比如远程调用较慢，可以用消息队列攒一堆去完成调用。

基于消息的模型，等通知即可，而不是处理（那是RPC），以及索引库更新，只是一个通知，而不是强完成（重量级），只是通知而不是职责所在（比如上游系统对下的通知）。

仅仅最终一致性。

需求场景

及一些非核心业务或者多个对象、数据量小时，而

相比RPC框架（dubbo等），RPC场景是需要强一致性、对延迟敏感、注重结果立马返回、重量级

4.应用拆分

SOA 微服务等

个人看法，原则是：

1.业务是否适合拆分，拆分后耦合度不能高

2.是否需要拆分，拆分是为了高并发高可用，是否解决了高并发热点问题？

5.应用限流

比如股票系统中，收盘后，你有几百万数据需要入库了，如果不做限流，瞬间将会把带宽全部打满，其它服务暂时GG或者主从延迟很大等等问题。

限流的算法

常见的限流算法有：计数器、漏桶和令牌桶算法。

计数器

计数器是最简单粗暴的算法。比如某个服务最多只能每秒钟处理100个请求。我们可以设置一个1秒钟的滑动窗口，窗口中有10个格子，每个格子100毫秒，每100毫秒移动一次，每次移动都需要记录当前服务请求的次数。内存中需要保存10次的次数。可以用数据结构LinkedList来实现。格子每次移动的时候判断一次，当前访问次数和LinkedList中最后一个相差是否超过100，如果超过就需要限流了。