数据层：

    缓存：

        缓存穿透（注：如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就会挂掉）

            方案1    布隆过滤器（bloomfilter）（注：布隆过滤器可检索一个元素是否在一个集合中。优点：空间效率和查询时间都比一般的算法要好的多，缺点：有一定的误识别率和删除困难。）

            方案2    缓存 NULL（注：不管是数据不存在，还是系统故障。我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟）

        缓存雪崩（key集体过期）     

            方案1    缓存失效时间增加小随机数，避免集体失效 

            方案2    永不过期，旁路进程扫描替换过期数据

        缓存击穿（单热点key 注：缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。）  

            方案1    分散热点key为多个子key，对应相同的value存储在不同服务器上，分散单机压力 （注：hystrix，可以做资源的隔离保护主线程池，把这个应用到缓存的构建也未尝不可）

            方案2    （针对单机的多进程）单进程更新缓存，加分布式锁，其他进程等待，避免数据过期时恰有大量的并发请求压向存储系统；（注：分布式锁 如reids setnx 确保一个时间段内只有一个进程访问db更新）

            方案3    （针对单机的多进程）“提前”使用互斥锁：内部超时时间（小于实际超时时间）一到，马上更新超时时间（其他进程则认为没过期）并加载db缓存。（注： 在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中）

            方案4:    永不过期    （注：1.redis永不过期    2 如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期）

       本地缓存中间件：guava cache（Google开源）

       服务端缓存中间件：memcached、redis、Tair（淘宝开源分布式kv缓存系统）

    一致性：

        CAP原则

            分布式锁

                数据库分布式锁：简单易理解；单点、性能差、不可重入。（注：乐观锁，悲观锁，mvcc）

                缓存分布式锁：非阻塞性能好；复杂容易死锁。（注：Memcached 可以使用 add 命令，该命令只有KEY不存在时，才进行添加，或者不会处理。Memcached 所有命令都是原子性的，并发下add 同一个KEY ，只会一个会成功）

                Zookeeper分布式锁：通过有序临时节点实现锁机制。（注①）

                redis分布式锁：基于setnx(set if not exists)，单进程单线程模式不用加锁。

            一致性算法

                Paxos

                Zab（Zookeeper中的分布式一致性算法）

                Raft（etcd使用raft协议）：正确高效简洁。通过随机等待的方式发出投票，的票多者获胜。

                Gossip

            幂等（重复调用的结果相同）  常见手段：悲观锁、乐观锁、唯一索引、一次性token、序列号等。（注：这里秒数可能抽象，举个例子：姓名和电话的组合在mysql中不能重复，我们可以新建一个唯一索引，对姓名和电话拼接成的字符串进行md5加密）

    主从架构

         一般主从系统都会选择强一致协议，即主节点采用将数据发送给从节点收到响应成功后，才会将数据持久化到本地，返回用户成功。

        单点问题（应尽量减少与单点的交互。两种常见方法：批量写 和 客户端缓存。）

            双主架构：

                1.一台主库(我们称之为master-01)提供服务，只负责数据的写入；

                2.拿出一台数据库服务器(我们称之为master-02)资源做master-01主库的从库(之间做主从同步)；

                3.两台主库之间做高可用,可以采用keepalived等方案(一定要保证master-01同时也要作为keepalived的主)

                4.程序在调用主库IP地址的地方写为高可用的VIP地址；

                5.所有提供服务的从服务器与master-02进行主从同步；

                6.建议采用高可用策略的时候，当master-01出现问题切换到master-02的时候，即使master-01恢复了，也不要让它去自动承接VIP地址，否则可能造成数据的混写；

            影子master架构：

                shadow-master是一种很常见的解决单点高可用问题的技术方案。业内经常使用keepalived+vip的方式实现这类单点的高可用）

            中心调度节点通常直接用zookeeper消灭单点。

    去中心化架构（略）

         Quorum协议，多数派原则。

    唯一ID生成：

        核心思想是结合服务/机器、时间、随机数来组合生成UUID。

    一致性hash：

        确保在缓存服务器节点数量发生变化时大部分数据保持原地不动。

    数据库扩展

        通常mysql单库5千万条需要分库（最好能拆分到1千万以内）。

        问题：事务、Join、数据迁移、容量规划和扩容、ID路由、分页等。

        分库分表中间件：sharding-jdbc(当当)、Tsharding(蘑菇街)、Atlas(奇虎360)、MyCAT(阿里)、Vitess(Google)等