为系统扩展而采取的一些措施——缓存

1. 缓存
   1.1 缓存刷新机制，缓存刷新是指什么时候把数据库中的数据加载到缓存
   （1） 定期刷新；
   （2） 缓存命中失败时刷新；
   1.2 在有缓存时的数据写入方式：
   （1） 同步写入，即缓存和数据库同时被写入，即在应用层进行双写操作，这种方式可以有效保证缓存和DB中数据的一致性，由于这种方式即要更新缓存同时还要更改数据库，其访问效率相对较低，适合读多写少的场景；
   （2） 异步更新机制，在写操作时只写入缓存便返回，写数据库的操作交个另外一个异步操作来完成，这样可以加快用户请求的处理速度，进而增强整个系统的并发量，但是这种方式会造成在一定时间内缓存和数据库中的数据不一致；
   一般情况下，同时保证数据写入缓存和数据库的事务性是非常困难的，因为这时涉及到写入数据到两种系统中，而且一般缓存不提供回滚机制，如果系统的要求不严格，则可采用一些妥协措施，以提升系统的整体访问效率。
   1.3 缓存使用的几种方式：
   （1） 全量缓存，是指所有的数据在缓存中都有，它不适合数据量较大、冷热访问极度不均匀的情况，这些情况下要么缓存放不下这么多数据，要么缓存中加载的都是大量不用的数据，造成缓存浪费，同时也会影响访问效率；它适合数据量小并且全部数据都会经常被访问的场景；例如，我们有一个业务是获取系统中各子服务的地址，在每个客户端上线时第一步操作就是获取各子服务的地址，然后才能进行真正的业务操作，这些服务地址信息数据量不大，但是全部都会经常被访问，因此它们需要被全量缓存，为保障缓存和数据库的一致性，我们采用双写策略，更新服务地址时要同时更新缓存和数据库；
   （2） 只缓存热点数据，这种方式适合数据量大、冷热访问不均匀的场景，该方式涉及到数据何时被加载、何时被逐出的问题；加载时可以采用两种方式：增量方式，服务启动时不向缓存中加载任何数据，等访问时在缓存找不到再去数据库中取并将取出的结果加载到缓存中，这样随着时间的推移，热点数据将被加载到缓存中；另一种方式是减量方式，服务启动时加载全部的数据，一定时间内不被使用的数据将会被逐出，随着时间的推移冷数据都被逐出，而留下来的都是热点数据；例如：我们为一个IM系统设计账号服务子系统时，就采用只缓存热点数据的方式，并且数据加载方式采用增量方式；只缓存热点数据的方式要特别注意缓存的量，如果缓存中没有存下足够的热点数据，那么将会有一定量的请求会穿透缓存，将压力施加到数据库上；
   1.4 架构设计时的三个层次的缓存
   （1）对象缓存，例如Redis、Memched等，它以Key-Value的方式帮助我们缓存一些对象数据，Redis提供的Value类型更多，使用时更加方便；但是这些缓存通常不提供数据库的事务性，即它不满足ACID的四点要求，在分布式系统中我们更常提及的是CAP特性，即在分布式环境中无法同时满足：一致性、可用性和分区容忍性，因此，在做分布式系统中要对业务进行更细粒度的分析，确定哪些数据需要事务性存储，哪些只需CAP中的两点即可满足？按照这种思路，一般一个系统中只有极少数核心的数据要求事务性，绝大多数数据可能要求最终一致性等等。
   （2）应用缓存，例如代理缓存和反向代理缓存，应用缓存的目的是加快用户的访问速度和尽量降低对资源的使用率；代理缓存的例子，例如互联网服务提供商（ISP）缓存了一部分常用URL对于的资源，当用户访问这些URL时，ISP直接从缓存中把结果返回给用户，而不是将用户请求转交给URL所指向的真正服务器；反向代理的例子，在服务前面部署一个nginx用于缓存静态页面，当用户访问这些静态页面时，反向代理nginx直接将缓存的静态页面返回给用户，这些请求就不会落到后面的真正服务器上，反向代理服务对访问服务后台的所有请求进行了过滤、拦截，大大降低了请求对后端的压力；
   （3）内容交付网络缓存，最典型的例子就是CDN，在视频点播网站中，如果我们点播的电影都在中央的资源服务器中，那么这个服务的性能再强大也难以为用户提供流畅的视频服务，采用CDN之后，就可以根据用户的访问情况，将热点数据推送到距离用户最近的边缘资源服务器上，这样用户在观看视频时就直接从边缘资源服务器上进行下载，这样资源离用户更近，下载速度更快；
   1.5 个人理解，在进行高并发服务的设计时，应该采用逐级分流的策略，将用户的请求呈树状分流到各个服务中，用户经常访问的请求被放在树状服务的上层，业务处理越复杂的请求被放在树状服务的下层；如下图所示：