缓存读写--写

在上一篇文章中我们讨论了缓存架构方案，使用这个架构方案可以减轻读数据库的压力，但是这个方案在大量并发写操作的情况下会造成数据库性能降低。那么这篇文章我将讲解一下如何处理大量并发写的问题。

一、案例

在一个电商系统中，我们要增加一个预约功能，用户可以在指定的时间段内对商品进行购买预约。预约功能和其他功能不一样的地方是，预约功能会出现短时间内大量并发写的情况，很有可能造成数据库和服务器崩溃，对于服务器来说我们可以增加服务器数量，但是对于数据库来说简单的增加数据库数量是不够的。一定有人会说使用分表分库啊，这个方案确实不错，但是预约功能并不是每天都有的，这么做又有些大材小用。因此在这里我推荐使用缓存层（又称写缓存）作为解决大量并发写的方案。每个预约请求经过校验后将先将数据存放在高性能的缓存中，这样大量的写操作会首先冲击缓存层，当缓存层中的数据达到某个阈值的时候再将其中的数据批量落库。（这里的缓存层大部分情况优会使用NoSQL来实现）优点是利用缓存的高吞吐能力来承受洪峰流量。

二、思路

写缓存需要考虑五个问题：

1. 写请求和批量落库是同步操作还是异步操作；
2. 落库如何触发；
3. 如何存储缓存数据；
4. 并发操作缓存层应注意哪些问题；
5. 批量落库失败了怎么处理。

2.1 异步还是同步

2.1.1 . 同步

写请求提交数据后，当前写操作线程会等到批量落库完成后才返回结果给用户。优点是用户预约成功后，可以在预约页面马上看到自己预约的信息，缺点是用户在提交预约请求后需要等待一段时间&#x