背景需求
在并发环境中，大量读/写请求涌向数据库，磁盘的速度明显与内存不同。 从减轻数据库压力、提高系统响应速度的观点出发，通常在数据库之前添加缓存。 由于一台机器的内存资源和承载能力有限，而且大量使用本地缓存会在不同的节点上存储多个相同的数据，对内存资源造成巨大的浪费，因此产生了分布式缓存。
Memcache
memcache是一个开源、高性能的分布式内存对象缓存系统，它减少了对APP应用程序中数据库的访问，加快了对APP应用程序的访问，并降低了数据库的负载。 为了能够快速检索内存中的数据，memcache以key-value的形式存储和访问数据，并在内存中维护巨大的HashTable，从而将数据查询的时间复杂性降低到o(1)，并对数据执行高性能访问如果内存容量始终有限，且内存中没有足够的空间存储新数据，memcache将使用最近访问频率较低的数据(LRU )并存储新数据(原理请参照链接)
memcache存储支持的数据格式也灵活多样。 通过对象序列化机制，可以将更高级别的抽象对象转换为二进制数据并存储在高速缓存服务器中，如果需要当前的APP应用程序，则可以反向序列化二进制内容，以将数据恢复回原始对象。
缓存的分布式体系结构
memcache本身不是分布式缓存系统，分布式是通过访问它的客户端实现的。 一种比较简单的实现方法是基于缓存密钥进行混列。 如果后端有n个缓存服务器，则要访问的服务器为hash(key ) %N。 这允许前端请求平衡地映射到后端缓存服务器。 但是，如果具有后端的缓存服务器宕机或群集压力过大，则还存在需要添加新的缓存服务器的问题。 大多数key将被重新定位，这对高并发系统来说可能会是一场灾难。 所有请求都像洪水一样涌向后端数据库服务器，如果数据库服务器不可用，整个APP应用程序都将无法使用，从而导致所谓的“雪崩效应”。
一致性散列算法(一致散列算法)在一定程度上改善了缓存雪崩问题。 删除/添加缓存服务器时，可以尽可能小地修改现有的key映射关系，以避免大量key的重新映射。 (原理请参照链接)
分布式会话
传统的APP应用服务器，如tomcat、jboss等，其本身实现的session管理大部分是独立的，在大型分布式站点中，支持其业务的不仅仅是服务器，还有要求在不同服务器之间跳转的分布式群集传统的网站通过将一些数据存储在cookie中来避免在分布式环境中处理会话。 这一方面弊端很多，另一方面cookie的安全性非常恶劣，而且cookie中存储的数据大小有限，随着移动互联网的发展，结合移动端会话的需要，使用cookie进行会话(算法请参照链接)
分布式会话解决方案
前端用户请求随机分发后，可能会命中后端的任何webserver，webserver也可能会因为各种不确定的原因而停机。 在这种情况下，session很难在群集之间同步，但通过将sessionid作为密钥存储在后端缓存群集中，无论请求的分配如何，webserver都可以在webserver关闭时与其他webserver保持同步这样可以实现群集之间的session同步，从而提高webserver的容错能力。
缓存容错
业务高度依赖缓存，缓存必须是灾难恢复：
1 .双人房相互备份
2 .复制了多个数据，禁用了一个缓存，可以在群集之间自动复制和备份
3 .数据库充裕
4 .百万卡
转载于链接：https://my.oschina.net/key ven/blog/1841321