数据库热点数据更新的思考

点击上方蓝色字体，选择“置顶公众号”

一起自学，一起进步

热点数据更新

对于有限的数据库资源，如果有大量请求去消费的话，肯定会产生大量的锁竞争（数据库对一条数据的更新会导致在索引上给这条记录加行锁，如果没有索引，会导致锁表），消耗服务器资源，而且请求的成功率也不高（换句话说就是你在浪费服务器资源，性价比不高）。例如：在大促某件商品时，库存只有 1000，用户请求数 100 w，如果都让这个 10 w 用户请求去访问数据库，会带来大量的锁竞争，最终抢到商品的请求数也比较少，请求的成功率也低, 因为你 100 w 个请求，最多也只有 1000 个请求成功。

这个问题反映了什么？

我们不应该把大量的请求直接访问数据库等比较核心的资源。这种场景又分为大量的请求是读请求还是写请求。

读请求

用缓存去抗就行。

写请求

那问题又来了，如何在业务层把大量请求拦截下来存放起来，然后以数据库可以接受的请求数去把这些请求批量放行呢？

常用的一种方案就是：消息队列。利用消息队列去做一个削峰填谷、流量控制，从而避免数据库被大量请求打垮，影响正常的服务提供。当然还可以对热点数据做隔离，以及对一些更新很频繁的场景，根据业务的特性去把这些多条 SQL 合并，一定时间内只要执行最后一条 SQL 就行了。

我们从上述这些描述又可以思考出哪些东西？

不管是操作系统对临界资源的并发控制，还是 Java 中 JUC 对临界资源的并发控制，以及我们业务对临界资源的并发控制，其实归根结底都有一种可重用的思想，那就是把访问这个临界资源的多个请求进行排队处理，同一时间只有一个请求在占用临界资源。当然这种排队处理并发的思想其实是一种悲观锁的思想。解决并发还有一种乐观锁的思想，在 Java 并发中就是 CAS，它与悲观锁的最大区别在于，CAS 允许多个请求都去尝试抢临界资源，但最终只有一个抢成功，其他的自旋重试。而悲观锁，只会放一个请求去抢临界资源，再来的新请求看到这个临界资源被占用就会直接入队，等待占用临界资源的请求释放锁。AQS 不也是这种思想吗？

最近项目比较急，没有时间写太多的文章。 感谢大家一直的关注，过几个月一定会有好的文章和福利给大家。

▼

往期精彩回顾

▼

Spring Context 你真的懂了吗

JDK1.6 对 synchronized 的锁优化

Java 泛型（上）

END

如果读完觉得有收获的话，欢迎点【好看】，关注【Java知其所以然】，查阅更多精彩历史！！！

让我“好看”