cache

aalansehaiyang · aalansehaiyang · commit ebabef2d89f9 · 2018-01-27T17:33:28.000+08:00
diff --git a/README.md b/README.md
@@ -71,7 +71,7 @@
 	* [ActiveMQ](https://github.com/apache/activemq)
 	* [RabbitMQ](middle-software/RabbitMQ.md)
 	* [Kafka](middle-software/kafka.md)
-	* [RocketMQ](https://github.com/apache/incubator-rocketmq)
+	* [RocketMQ](middle-software/RocketMQ.md)	
 
 *   缓存
 	* [redis](open-source-framework/redis.md)
diff --git a/basic-knowledge/spring.md b/basic-knowledge/spring.md
@@ -13,21 +13,21 @@
 
 
 
-**简介：**
+#### 简介
 
 一个应用非常广泛的java开源框架。主要分为两大块：IOC和AOP。
 
 
 `无论是技术类书籍或者网上资料、学习手册，非常多，此处就不详细列举`
 
-### 事务
-
-* [Spring事务传播性与隔离性](https://mp.weixin.qq.com/s/u4NLJ3I2vkeZHWBpgHsdEA)
-
-### 其它
+#### 文档
 
+* 事务
+	* [Spring事务传播性与隔离性](https://mp.weixin.qq.com/s/u4NLJ3I2vkeZHWBpgHsdEA)
 
 * annotation 重试配置
 	* [Spring重试支持Spring Retry](http://blog.csdn.net/jiesa/article/details/76549381)
 	* [https://stackoverflow.com/questions/38212471/springboot-retryable-not-retrying](https://stackoverflow.com/questions/38212471/springboot-retryable-not-retrying)
-* [Spring、Spring MVC、MyBatis 整合文件配置详解](https://mp.weixin.qq.com/s/8-XvEOA4WzrZwytOXpHHyw)
+
+*  框架配置
+	* [Spring、Spring MVC、MyBatis 整合文件配置详解](https://mp.weixin.qq.com/s/8-XvEOA4WzrZwytOXpHHyw)
diff --git a/basic-knowledge/springboot.md b/basic-knowledge/springboot.md
@@ -10,14 +10,15 @@
 * [代码热部署](springboot-hot-reload.md)
 * [eclipse中如何跑spring boot的单元测试](springboot-unit.md)
 
-#### 学习资料
+#### 资料
 
 * http://www.ityouknow.com/spring-boot
 * https://github.com/JeffLi1993/springboot-learning-example
 * https://github.com/spring-projects/spring-boot
 * http://www.jianshu.com/collection/f0cf6eae1754
 * http://zh.lucida.me/blog/java-8-lambdas-insideout-language-features/
-* 《SpringBoot揭秘--快速构建微服务体系》* 
+* 《SpringBoot揭秘--快速构建微服务体系》
+* [Spring干货汇总](https://mp.weixin.qq.com/s/VFHmOIp-H4lgh4gQE-cj5A)
 
 
 ---
diff --git a/middle-software/RabbitMQ.md b/middle-software/RabbitMQ.md
@@ -11,3 +11,4 @@
 * [快速入门及应用](https://mp.weixin.qq.com/s/GIkzoIBGQJtXB9RXlwlzPQ)
 * [从入门到精通](http://blog.csdn.net/column/details/rabbitmq.html)
 * [RabbitMQ分布式集群架构](http://blog.csdn.net/woogeyu/article/details/51119101)
+* [有货RabbitMQ双活实践](https://mp.weixin.qq.com/s/GC2N1i27eAo8QFuzb6muJw)
diff --git a/middle-software/RocketMQ.md b/middle-software/RocketMQ.md
@@ -0,0 +1,12 @@
+## RocketMQ
+----
+
+
+* [源代码](https://github.com/apache/incubator-rocketmq)
+
+---
+
+
+* [分布式消息队列 RocketMQ 源码分析 —— Message 拉取与消费（上）](https://mp.weixin.qq.com/s/HUNuqsjj88vcNA_BzORBcg)
+* [分布式消息队列 RocketMQ 源码分析 —— Message 拉取与消费（下）](https://mp.weixin.qq.com/s/J4awuLHrBvSOphsUIAMV4A)
+* [分布式消息队列 RocketMQ 源码分析 —— Message 顺序发送与消费](https://mp.weixin.qq.com/s/hf0ywoRa6A0NKYGEGQL2BQ)
diff --git a/other/book.md b/other/book.md
@@ -129,4 +129,5 @@
 *	《金刚经·心经》
 *	《人生可以走直线》
 *	《没有做不到的事，只有不会做事的人》
-*	《货币战争》
+*	《货币战争》
+*	《自控力》
diff --git a/other/person.md b/other/person.md
@@ -14,6 +14,7 @@
 * [职场“35岁危机”：这是我看过的最棒建议](https://mp.weixin.qq.com/s/TtOhnf7OcEwMOL5wc3DWqw)
 * [论三年内快速成长为一名技术专家](https://mp.weixin.qq.com/s/k6QeIzq3uL1pmmdnQB2AFg)
 * [快速成长为一名技术专家](https://mp.weixin.qq.com/s/a3X1J-TkJ3ThTdc0YCyIKw)
+* [美丽联合集团VP顶天：总结这一年，我们在技术上的变与不变](https://mp.weixin.qq.com/s/zMneLwJkhJ0jA96cIzxLKw)
 
 ---
 ### 技术（P） --> 管理（M）
diff --git a/system-architecture/architecture-experience.md b/system-architecture/architecture-experience.md
@@ -27,9 +27,12 @@
 ### 缓存
 
 * 	[cache相关](cache相关.md)
+*	[cache经验总结](cache-summary.md)
 *	[缓存架构之防雪崩设计](缓存架构之防雪崩设计.md)
 *	[大型web系统数据缓存设计](https://mp.weixin.qq.com/s/Imn4FuXv2hw3uocgZsBlOg)
 *	[cache常见的陷阱与坑](https://github.com/oldratlee/cache-practice)
+*	[缓存穿透、缓存并发、热点缓存之最佳招式](https://mp.weixin.qq.com/s/62KJ2mSTGoUTPsq0RjU7lg)
+*	[再谈缓存的穿透、数据一致性和最终一致性问题](https://mp.weixin.qq.com/s/kYXabyZhVthF-9rR0Uv4lQ)
 
 ### 高并发
 
@@ -87,3 +90,4 @@
 *	[好的架构是逐步演化过来的](http://mp.weixin.qq.com/s/KsFVTqDhYcO3Jws6oOoa4g)
 *	[技术不应成为业务的工具](http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993402&idx=1&sn=f79a2e2cd75bf7ca539149addb6e7c21)
 * [创业公司如何打造高效的研发体系？](http://mp.weixin.qq.com/s/iGTJy98Fj_qT0gBMHxzH1g)
+* [那么贵的技术会议，真的能学到东西吗？](https://mp.weixin.qq.com/s/pf-2pw0W4vKch7IDGTyzBw)
diff --git a/system-architecture/architecture-good-case.md b/system-architecture/architecture-good-case.md
@@ -56,6 +56,7 @@
 	* [点融支付系统架构的演进](https://mp.weixin.qq.com/s/823bGuLkU0uX-vHUYkr5jg)
 	* [易宝支付日志中心平台建设](https://mp.weixin.qq.com/s/Lsw_Ygyp50IJnqjzHxpGWg)
 	* [高并发支付场景分析及设计](https://mp.weixin.qq.com/s/syKnlmu_noyp0C4LeGp9Tw)
+	* [中小型研发团队架构实践之企业支付网关](https://mp.weixin.qq.com/s/rfeFWOq--0FXRa6r1eritQ)
 
 
 ---
@@ -222,6 +223,11 @@
 * ###### 微博
 	* [新浪微博混合云架构如何轻松应对热点事件的高峰值流量](https://mp.weixin.qq.com/s/6tSbQFgSff07VIZRHpfTQg)
 
+---
+#### 杂项
+
+* ###### 会员、注册、登录
+	* [单点登录怎么实现？](https://mp.weixin.qq.com/s/ZT1B6ziSSRW41FN33xA3ZA)
 
 ---
 #### 其它
diff --git a/system-architecture/cache-summary.md b/system-architecture/cache-summary.md
@@ -0,0 +1,178 @@
+## cache经验总结
+
+---
+
+### 为什么要使用cache
+
+关系型数据库的数据量比较小，以mysql为例，单表的量尽量控制在千万级别。
+
+关系型数据库在TPS上的瓶颈往往会比其他瓶颈更容易暴露出来，尤其对于大型web系统，由于每天大量的并发访问，对数据库的读写性能要求非常高;而传统的关系型数据库的处理能力确实捉襟见肘;以我们常用的MySQL数据库为例，常规情况下的TPS大概只有1500左右(各种极端场景下另当别论)。
+
+下面是MySQL官方所给出的一份测试数据：
+
+系统配置：
+
+Sun V40z / 4x 2390MHZ / Solaris 10 / 8GB RAM
+
+1m rows，Read Only，4 CPU
+
+|Connections| Trans/sec |
+|--|--|
+|1|382|
+|2|677|
+|4|1130|
+|8|1479|
+|32|1418|
+|256|947|
+|1024|224|
+
+[详细压测报告：](img/UC2005-Advanced-Innodb-Optimization.pdf)
+
+https://www.percona.com/blog/files/presentations/UC2005-Advanced-Innodb-Optimization.pdf
+
+对于一个PV上亿的网站，每一次请求涉及多次数据库交互，每天的读写请求量远远超过关系型数据库的处理能力，所以必须通过高效的缓存抵挡大部分的数据请求。
+
+### 缓存类型
+
+*  本地缓存
+
+	本地缓存会减少网络层的交互，无论是本地内存还是磁盘，速度比较快。但对分布式系统来讲有一个缺点，当数据库更新时，没有一个简单有效的方法去更新本地缓存。
+
+	**本地缓存适用两种场景：**
+	
+	* 一、对缓存内容时效性要求不高，能接受一定的延迟，可以设置较短过期时间，被动失效更新保持数据的新鲜度。
+	* 二、缓存的内容不会改变。比如订单号与uid的映射关系，一旦创建就不会发生改变。
+	
+	**注意问题：**
+	
+	* 内存Cache数据条目上限控制，避免内存占用过多导致应用瘫痪。
+	* 内存中的数据移出策略
+	* 虽然实现简单，但潜在的坑比较多，最好选择一些成熟的开源框架
+	
+*  分布式缓存
+
+	本地缓存的使用很容易让你的应用服务器带上“状态”，而且容易受内存大小的限制。
+	
+	分布式缓存借助分布式的概念，集群化部署，独立运维，容量无上限，虽然会有网络传输的损耗，但这1~2ms的延迟相比其更多优势完成可以忽略。	
+		
+	优秀的分布式缓存系统有大家所熟知的Memcached、Redis。对比关系型数据库和缓存存储，其在读和写性能上的差距可谓天壤之别，redis单节点已经可以做到8W+ QPS。设计方案时尽量把读写压力从数据库转移到缓存上，有效保护脆弱的关系型数据库。
+
+
+*  客户端缓存
+
+	大部分的web应用、微服务应用都会尽量做到无状态，方便于线性扩容。有状态的后端存储：DB、NoSQL、分布式文件系统、CDN等。
+
+	另一个很重要的就是客户端缓存了，对客户端存储的合理使用，原本每天几千万甚至上亿的接口调用，一下就可能降到了几百万甚至更少，而且即便是用户更换浏览器，或者缓存丢失需要重新访问服务器，由于随机性比较强，请求分散，给服务器的压力也很小。另外再加上合理的缓存过期时间，就可以在数据准确和性能上做一个很好的折衷。
+
+
+### 常用技术框架
+
+* Guave
+* Memcached
+* Redis
+
+更多缓存框架：http://www.oschina.net/project/tag/109/cacheserver
+
+### 更新策略
+
+* 被动失效
+
+	缓存数据主要是服务读请求的，通常会设置一个过期时间，或者当数据库状态改变时，通过一个简单的delete操作，使数据失效掉；当下次再去读取时，如果发现数据过期了或者不存在了，那么就重新去数据库读取，然后更新到缓存中，这即是所谓的被动失效策略。
+
+	被动策略有一个很大的风险，从缓存失效到数据再次被预热到cache这段时间，所有的读请求会直接打到DB上，对于一个高访问量的系统，很容易被击垮。
+
+
+* 主动更新
+
+	主动更新，很容易理解，就是数据库存储发生变化时，会直接同步更新到Cache，主要是为了解决cache空窗期引发的问题。比如电商的卖家修改商品详情，具有读多写少特点。
+
+	但如果是读多写多，同样会带来另一个问题，就是并发更新。多台应用服务器同时访问一份数据是很正常的，这样就会存在一台服务器读取并修改了缓存数据，但是还没来得及写入的情况下，另一台服务器也读取并修改旧的数据，这时候，后写入的将会覆盖前面的，从而导致数据丢失。解决的方式主要有三种：
+
+```
+	1、锁控制。这种方式一般在客户端实现(在服务端加锁是另外一种情况)，其基本原理就是使用读写锁，即任何线程要调用写方法时，先要获取一个排他锁，阻塞住所有的其他访问，等自己完全修改完后才能释放。如果遇到其他线程也在修改或读取数据，那么则需要等待。锁控制虽然是一种方案，但是很少有真的这样去做的，其缺点显而易见，其并发性只存在于读操作之间，只要有写操作存在，就只能串行。
+
+	2、单版本机制（乐观锁）。为每份数据保存一个版本号，当缓存数据写入时，需要回传这个版本号，然后服务端将传入的版本号和数据当前的版本号进行比对，如果等于当前版本号，则成功写入，否则失败。这样解决方式比较简单;但是增加了高并发下客户端的写失败概率;
+
+	3、多版本机制。即存储系统为每个数据保存多份，每份都有自己的版本号，互不冲突，然后通过一定的策略来定期合并，再或者就是交由客户端自己去选择读取哪个版本的数据。
+```
+
+### 序列化
+
+分布式缓存的本质就是将所有的业务数据对象序列化为字节数组，然后保存到自己的内存中。所使用的序列化方案也自然会成为影响系统性能的关键点之一
+
+* 序列化速度
+* 对象压缩比例
+* 支持的序列化数据类型范围
+* 反序列化的速度
+* 框架接入易用性
+
+常见的序列化框架：
+
+* Java源生序列化
+* Hessian
+* Protobuf
+* Kryo
+
+### 开发注意事项
+
+* 评估当前业务使用的空间大小。避免空间不足，导致热数据被置换出去，影响缓存命中率
+* 不要把缓存当DB使用，因为它会丢失
+* 最好设置过期时间，可以自己回收
+* key定义遵循一定规则，相同业务采用同一前缀
+* 缓存对象粒度。高内聚低耦合，考虑尽可能复用，不要一个小字段修改导整个大对象全部失效
+
+```
+方案一：
+uid---> 发过的贴子内容列表
+
+方案二：
+uid--->发过的贴子tid列表
+tid--->贴子内容
+
+```
+
+* 另外缓存对象大小要控制，不要过大，占用过多带宽。之前遇到过一个业务团队，单key下挂了5M的大对象，每次用时，从缓存中取出，反序列化，然后取其中一小部分。后来随着业务并发量上升，把网卡打爆，进而影响其它正常业务访问。
+* 根据业务需求，选择合适的缓存框架，比如memcache只支持kv对存储，redis则支持较丰富的数据结构
+* 是否要引入多级缓存，本地内存--》非持久化缓存（如memcache）---》持久化缓存---》DB，要注意数据一致性问题
+* 提前考虑扩容问题
+
+
+### 问题汇总
+
+##### 1、缓存穿透
+
+我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。那这种问题有什么好办法解决呢？
+
+有一个比较巧妙的做法是，可以将这个不存在的key预先设定一个值。比如，"NULL" ，在返回这个NULL值的时候，我们的应用就可以认为这是不存在的key。
+
+缓存穿透如果被恶意攻击，造成的影响面很容易放大。比如文章详情页，查询一个不存在的tid，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。
+
+##### 2、缓存集体失效
+
+对于一些活动期间的数据通常会提前预热到缓存中，并设置一个过期时间，如果系统的并发量很高，恰巧缓存又失效了，此时会将压力转嫁给后面的DB，很容易击垮系统。
+
+那如何解决这些问题呢？
+
+其中的一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。还有一种方式，就是计算好缓存的过期时间。
+
+##### 3、DB和缓存不一致
+
+当修改了数据库后，没有及时修改缓存，或者缓存服务器挂了。如果是因为网络问题引起的没有及时更新，可以通过重试机制来解决。而缓存服务器挂了，请求首先自然也就无法到达，从而直接访问到数据库。那么我们在修改数据库后，无法修改缓存，这时候可以将这条数据放到数据库中，同时启动一个异步任务定时去检测缓存服务器是否连接成功，一旦连接成功则从数据库中按顺序取出修改数据，依次进行缓存最新值的修改。
+
+##### 4、命中率较低，影响性能
+
+* 过期时间太短， 这种场景可以根据实际情况适当增大过期时间
+* 存在不合理缓存删除逻辑， 导致有效的缓存频繁被删除
+* 不合理的key规则设计， 每次缓存访问的key都在变化， 导致无法命中缓存和频繁的新缓存创建
+* key确实不存在，但是应用还是在频繁的访问， 这种应该从业务逻辑上杜绝
+
+### 性能指标
+
+* 缓存空间的使用率
+* topN 命令的执行次数
+* 缓存的命中率
+* 缓存的接口平均RT，最大RT，最小RT
+* 缓存的QPS
+* 网络出口流量
+* 客户端连接数
+* key个数统计
diff --git a/system-architecture/img/11.png b/system-architecture/img/11.png
diff --git a/system-architecture/img/12.png b/system-architecture/img/12.png
diff --git a/system-architecture/img/UC2005-Advanced-Innodb-Optimization.pdf b/system-architecture/img/UC2005-Advanced-Innodb-Optimization.pdf
