高并发系统中的常见问题

    本文一共分析了三个案例，分别介绍并发系统中的共享资源并发访问、计算型密集型任务缓存访问 、单一热点资源峰值流量问题和解决方案。

Q1：订票系统，某车次只有一张火车票，假定有1w我的同时打开12306网站来订票，如何解决并发问题？

A1： 首先介绍数据库层面的并发访问，解决的办法主要是乐观锁和悲观锁。

乐观锁

假设不会发生并发冲突，只在提交操做时检查是否违反数据完整性。

乐观锁使用一个自增的字段表示数据的版本号（或者timestamp），更新的时候检查版本号是否一致，好比数据库中版本号为4，更新时版本号使用版本号version=5，与数据库中的版本号version+1=（5）作比较，若是相等，则能够更新，若是不相等，其余程序已更新该记录，返回错误。

悲观锁

假定会发生并发冲突，屏蔽一切可能违反数据完整行的操做。

通常须要使用数据库的锁机制，好比MysqlInnoDB引擎的行级锁。

结论：在实际生产环境中，若是并发量不大且不容许脏读（原始数据为5，AB两个事务，B其余事务更新数据为2，事务未提交时，A读取到的仍然为5），可使用悲观锁。并发访问量大时，使用悲观锁有很是大的性能问题，能够选择乐观锁。

其次，介绍一下Memcached的CAS机制

CAS，又称Compare-and-Swap，表明一种原子操做。

Memcached的CAS机制解决的问题及其原理：

1. 实现了Check-and-Set原子操做功能；
2. 其使用方式为：首先使用gets指令一个key-value及key对应value的版本号；其次操做产生新的value值；最后使用cas指令从新提交key-value，并附带刚刚得到到的版本号；
3. 当服务端判断cas操做中的版本号不是最新的时，则认为改key的值已经被修改，本次cas操做失败。程序设计人员经过CAS机制可实现自增和自减的原子操做；

能够看到MemCache的CAS机制和数据库的乐观锁实现原理很是相似。

 

Q2：假设系统中图片存储在TFS（Taobao File System)中，接口提供缩略图服务，首先在缓存中查找是否有缩略图，若是没有，则从TFS加载原图片，而后请求缩略图服务，缩略图计算完成后，设置回缓存服务中。

遇到的问题：当一张图片分享给100w我的之后，同一时间有1w个并发请求，因为缩略图计算耗时较长（假设1s), 在这1s内，每一个请求查询缓存都没有找到而后申请计算缩略图，致使重复的缩略图计算量和资源消耗。

  

A2： 对于缩略图这种耗时的服务，很是适合使用缓存，不过在使用的时候，对于同一个图片，原则上只须要计算一次缩略图，在缩略图未计算完成时，能够对每张图片作 额外的标记表示其正在Processing，并发请求遇到缩略图Processing时，能够等待缩略图计算完成（这是建议的方式）后从缓存直接读取，也 能够是直接返回错误，经过客户端重试来解决。

     本案例中，若是缩略图请求在上传图片1分钟后才发生，则能够在后台预先计算缩略图并存储到缓存。另外就是在上传图片的时候计算缩略图，不过会增长上传图片的时间。

 

Q3:单点峰值流量，在并发系统中，除了请求总体的并发量高，还常见单一热点资源的并发请求量很高。例如，1万我的每人分享了一张图片，其中9999张图片的缩略图请求在10 QPS之内，剩下的一张图片为新闻热点图片，峰值请求在10万QPS左右， 系统会遇到的容量问题包括：1）接口前端机容量不够；2）缓存资源单实例遇到瓶颈。

A3:针对单点峰值流量可能遇到的性能瓶颈，解决方案以下。

1）接口层容量不够：这个问题比较简单，只要接口层设计是无状态的，当容量达到预警线，能够经过快速水平扩容解决。

2）缓存资源单实例遇到性能瓶颈：若是使用的是分布式缓存，当但愿突破单一key的访问瓶颈时（这个瓶颈既有多是CPU资源紧张，也有多是单机网络带宽跑满，还有多是磁盘IO吞吐不够），一个办法是分布式缓存作多副本（x3）冗余设计，这样系统的吞吐量（x3）能够提升3倍，不过成本也提升3倍。另一个办法是针对极热点数据，除了分布式缓存，同时在前端机上打开localCache，依靠数量众多的前端机来抗极热点请求。

        纯ad:欢迎你们关注微信公众号:neihanrukou