使用缓存降低数据库并发读写
前言
随着系统的并发量增加，数据库的并发读写最终将成为整个提供的瓶颈，甚至压垮整个数据库，导致系统卡死等严重问题。通过缓存是缓解数据库压力的重要手段，通过缓存把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。
缓存设计思想及方案
缓存设计最核心的原则就是让数据离用户更近。优秀的缓存设计直接影响到系统的高并发性能和响应速度，甚至影响客户体验。
缓存有三个作用范围：
- 事务、
- 应用、
- 集群
缓存设计方案
缓存按照存放位置不同可以分为客户端缓存和服务端缓存。
缓存分层
客户端缓存:
- 浏览器缓存
- 网关及代理服务器缓存：
服务器缓存：
- 本地缓存：
- 分布式缓存：
- 数据库缓存：
一个好的缓存设计方案需要综合考虑缓存的存储、使用时机、优缺点、以及分布式高并发下缓存一致性、缓存命中、缓存击穿/雪崩等问题。
缓存详细设计方案
客户端缓存
客户端缓存通常指web前端缓存，可以分为：浏览器缓存和代理服务器缓存。是目前网站前端加速的主要方式，其实现基本方式是：将制定的网站资源（整体页面、静态文件（js、css、图片）等）周期性缓存起来，缓存时间可以从几秒到几天不等，极大减少了网站应用服务器和数据库负荷。
浏览器缓存
浏览器缓存是最靠近客户的缓存机制，当开启浏览器缓存后，客户访问同一个页面将不从服务器下载页面，也是从浏览器本地缓存目录读取页面，然后在浏览器中展示。对于不常变化资源可以使用强制缓存策略，而精彩变动资源可以禁止浏览器缓存。浏览器缓存更新问题解决：可以在资源的引用地址（路径）后面增加hash、版本号等动态字符，从而达到更新资源引用URL目的，让之前的缓存强制失效（PS：其实并未立即失效，而是不在使用）。
网关或代理服务器缓存
将网页缓存到代理服务器上，多个用户访问同一个页面时，将直接从代理服务器把页面传送给用户。常见实现如，Ngnix反向代理缓存。使用反向代理服务器缓存实现简单，通常通过简单配置便可以实现，而不需要外增加代码开发。反向代理服务器缓存适合实时性要求不高或者经常不变的页面，如果门户首页、商品详情等页面。
服务端缓存
在服务端编程中，缓存主要是将数据库中数据加载到内存中，之后对该数据的读写都是在内存中完成，减少对数据库的访问，是解决高并发场景数据库并发读写瓶颈的主要手段之一。同时基于内存的读写处理速度高于磁盘I/O，缓存也是提高服务响应速度和性能重要手段。
根据缓存是否与应用在同一进程，可以将缓存分为本地缓存和分布式缓存：
- 本地缓存：应用同一进程内存空间缓存数据，数据读写都在同一进程。
- 分布式缓存：独立部署的进程，通常与应用进行部署在不同机器，缓存的读写需要通过网络来完成数据的传输。
本地缓存
本地缓存优缺点
- 访问速度快，但无法缓存大数据：本地缓存不需要跨网络传输，性能更好，但是由于本地缓存使用应用进程的内存空间，不能进行大数据存储。
- 集群数据更新问题：本地缓存只支持本地进程应用访问，其他进程应用无法访问，因此需要额外的机制来保证数据的一致性，实现复杂度高且容易出错。比如通过redis或zookeeper实现分布式同步。
- 数据随应用进程重启而丢失。
适用场景
本地缓存适用于缓存只读数据，如字典、统计类数据，以及进程独立数据，如本地长连接服务。
本地缓存实现
- Java堆缓存
使用Java堆内存来缓存数据。没有对象的序列化和反序列化，是最快的缓存。在编程中常用HashMap和ConcurrentHashMap来实现本地缓存。Java堆缓存应该避免大数据量缓存（可能导致GC停顿时间过长），同时可以使用软引用/弱引用来缓存对象，可以使当内存不足时，强制回收这部分对象，释放内存。Java堆内存一般用于缓存存储较热的数据。 - memcached/ecache
ecache是基于java的开源高效的、进程内缓存解决方案。ecache轻量、简单，被广泛应用于其他ORM框架数据缓存的底层实现（如Hinernate）。
memcached和ecache实现原理类似，基于K-V将数据缓存到内存，memcached支持多线程操作。相比ecache，memcached更加灵活。 - caffeine
Caffeine是基于Java 8的高性能缓存库，可提供接近最佳的命中率。Caffeine与ConcurrentMap类似，但是Caffeine与ConcurrentMap最根本的区别是，ConcurrentMap会保留添加到其中的所有元素，直到将其明确删除为止，而Caffeine能自动的回收存储的元素。
通过caffeine基准测试，可以看到caffeine在读写方面明显优与其他框架，在缓存命中率上Caffeine也不同于Guava，采用了更为优秀的Window TinyLfu算法，该算法是在LRU的基础上改进的版本。
分布式缓存
分布式缓存也叫进程外缓存，通常是独立于应用部署，通过网络进行缓存读写的数据传输。
分布式缓存优缺点
- 支持大量数据存储，不受应用进行重启影响：分布式缓存是独立部署的进程，拥有独立的内存空间，并且一般以集群的方式拓展，故而可以进行大数据储存。
- 数据集中存储，保证数据一致性：当应用采用集群部署时，集群每个节点通过统一的分布式缓存服务进行数据的读写操作，不存在本地缓存中数据更新问题，保证不同节点应用进行的数据一致性问题。
- 数据读写分离、高性能、高可用：分布式缓存一般支持数据副本机制，可以实现读写分离，可以解决高并发场景中数据读写性能问题。并且由于在多节点缓存冗余数据，提高了存储数据的可用性，避免某个节点宕机导致数据不可用。
- 数据基于网络传输，性能低于本地缓存。
分布式缓存实现
redis/memcached
分布式缓存一致性方案
缓存一致性问题主要是数据库和缓存的读写一致性问题。
首先给缓存设置过期时间是保证缓存最终一致性解决方案，所有数据的写操作以数据库为准，对缓存尽最大努力。
缓存更新策略：
先更新数据库再失效缓存
- 失效：应用先从缓存获取数据，如果没有从数据库读取，成功后放入缓存。
- 命中：应用从缓存读取数据，命中后返回
- 更新：先更新数据库，然后失效缓存（延时双删）
缓存穿透及解决方案
缓存穿透是指key对应的数据源不存在，导致每次针对key的请求都无法从存储层获取数据并写入到缓存，从而每次请求都落到数据库，失去了缓存意义。流量大时可能就拖垮了DB。
解决方案
- 方案一：对于查询返回为空的数据，仍存储到缓存（需要设置缓存过期时间尽可能短）
- 方案二：使用布隆过滤器，将可能存在的数据hash到足够大bitmap中，一个一定不存在的数据可以通过布隆过滤器拦截掉。
缓存击穿及解决方案
缓存击穿主要出现在高并发的热点数据访问场景。导致缓存击穿原因主要是同一时间发生消除读写（删），导致并发下缓存失效。或者是并发读取缓存时，恰巧达到缓存失效还来不及从数据库读取并写入缓存。
解决方案
- 比较常见的方法是使用使用互斥锁（mutex）机制，当缓存失效时，不是立即去load DB，而是先执行set mutex(比如redis的setnx)，如果操作成功，则load DB并写入缓存，如果操作失败则重试get缓存。
- 另外可以对某些静态热点数据使用永不过期策略。
缓存雪崩及解决方案
是指设置缓存相同的过期时间，如果一些应用初始加载缓存，采用并发写策略（多线程），导致了某一时间缓存全部失效，请求全部转发到DB，DB瞬时压力过大雪崩。高并发应用的缓存雪崩对于底层系统冲击非常可怕。
解决方案
- 考虑加锁或者队列方式写缓存，避免缓存过期时间一致
- 在设置缓存是在原有缓存失效时间基础加上一个随机值，降低过期时间的重复率。
