=====吞吐量-汇总======
通用原则：
容量按照峰值的5倍冗余计算；
数据容量按照存储30年计算；
应用服务器：
性能：读写均为5千/s；
计算原则：按照读写吞吐量计算数目；
Redis：
性能：单端口读5万/s，单端口写5万/s，内存容量32G/16G；
计算原则：按数据量大小确定服务器数量，吞吐量通过不是瓶颈；
Kafka：
单机读：5万/s，单机写：5千/s；
计算原则：按读写吞吐量计算数目，数据量通常不是瓶颈；
MySql：
性能：单端口读1000/s，单端口写700/s，单表容量5000万条，单条数据库记录大约1KB，数据库响应时间为几毫秒~几百毫秒；
计算原则：吞吐量确定服务器数，数据容量决定分库分表数目；即按照读写吞吐量确定数据库服务器数目；确定数据库数目，考虑到未来不用拆分数据库，可设计为32库/16库；确定数据表数目，按照总数据量条数/(服务器数*数据库数)；
其他性能：
SATA硬盘：随机读取可达到2MB/s
千兆网卡传输速度为128Mbit/s，读取1MB数据：10ms
同一机房网络来回：0.5ms，异地机房来回：30-100ms，可设置500ms以上为超时；
日志处理成功+存储： 时间约20ms
网页加载：几秒
计算案例：
12306网站实现10万/s查询量的缓存架构设计 ---- 详见《可伸缩服务架构---李艳鹏》4.1
系统容量评估 ----- 详见《分布式服务架构：原理--李艳鹏》3.4.4
http://www.infoq.com/cn/articles/practice-of-yhd-lottery-system-architecture/ ----- 从限流削峰到性能优化,谈1号店抽奖系统架构实践
===================版本总结====================
1. kafka：0.10 ----> 2017.4.26
2. redis : 3.2/2.8 ---> 2017
====================框架使用案例==============================
dubbo-性能和案例：
1. dubbo协议使用注意事项，详见《可伸缩服务架构》8.3.4
2. 在dubbo线程方面踩过的坑，详见《可伸缩服务架构》8.4.3
3. dubbo的I/O线程数默认为核数+1，业务调度线程池默认为200
5. dubbo项目线上案例解析，详见《可伸缩服务架构》8.7
(1)耗时服务耗尽了线程池的案例：
(2)容错重试机制引发服务雪崩案例：因第三方HTTP网络抖动等原因导致第三方接口无法在5秒内返回，消费端就会超时，并且不断重试3次，最后导致重试机制引发的服务雪崩；解决过程为：通过jstack看到晚上2点有大量失败的HTTP请求，定位为消费端超时时间设置<服务端的10秒，解决方案是：修改客户端超时时间，大于服务提供端的超时间，另外将容错模式修改为Failfast，让消费端应用自行处理；
数据库-性能和案例：
1. mySQL数据库单表存储5000万条数据已经达到极限
2. 分库分表数量划分和评估，参考《分布式服务架构：原理、设计和实战》第3章
分布式定时任务：
？？？
JVM性能调优：
？？？
日志相关案例：
1. log4j：多线程同时使用一个logger时，使用的是同步锁，影响并发性
复现：
解决：《分布式服务架构原理.设计与实战-李彦鹏》4.1.3.3
2. log4j: 不使用%L\%M\%F等输出文件的行号、方法名、文件名等
原因：上面信息是log4j通过构建异常并从异常堆栈中提取的信息；
详解：《分布式服务架构原理.设计与实战-李彦鹏》4.2.5
3. log4j：案例--1行日志导致的线上事故
详解：《分布式服务架构原理.设计与实战-李彦鹏》4.2.6
4. 日志系统的容量和性能评估
详解：《分布式服务架构原理.设计与实战-李彦鹏》4.3.8
大促案例：
1. 高性能高并发系统的稳定性保障 http://www.cnblogs.com/zengkefu/p/6372157.html
2. 大促场景备战思路-开涛：https://mp.weixin.qq.com/s/MWkfnXbBD1c-MOzb_BCsPw