版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
6大原则总结
- Vertical Scalability 更强的cpu，比如之前在连连，加密机能力不够，后来直接将4c8g改为16c32g，一举解决了问题，这个方式最快，但是
有天花板，不能无限用 - Horizonal Scalability 横向扩展，加机器，原则是应用服务器要是无状态的，见如下
- Caching 互联网是读多写少，一些不怎么变化的信息要缓存起来，甚至twitter会将动态内容事先转化成静态html，和如下第5条相关
- Load Balancing 负载均衡，和横向扩展相关联
- DB replication 主从结构，互联网是读多写少，读都是分开读
- DB partition 就是分库分表
Clone（其实就是横向扩展）
应用服务器不能存储用户session信息，也不能存储profile信息，总之这个信息是无状态的，这样某台挂了后，很容易切到另外一台
Nosql insteadOf mysql
第一章讲到clone人的进攻，因为无状态，且不是垂直扩展，所以横向扩展是没问题，不会有天花板，但是体系内的其他成了短板
比如数据库
- 第一条路是 分库分表 sql调优，但是作者建议在规模不可控制前，一开始就nosql
- 之所以nosql是因为互联网的数据特征，比如音频文件，视频文件，图片文件，这种用nosql好很多
但是要注意，如果有很多关联查询（select a., b. from TableA, TableB where a.id = b.id）那又很慢了
用好Cache！用内存的高速性（比如redis）代替磁盘的缓慢性
- 缓存查询结果，但是容易有过期的问题（不建议）
- 缓存对象，这也是圈圈目前在用的
文章中建议了一种更加异步的方式，所以请求都访问redis，背后是一组worker线程，不停地将数据从数据库搬运到redis（也就是应用服务器不直接访问数据库）
哪些对象适合缓存 - 用户session
- 热点博客
- 用户和朋友的关系
- 热门视频
- 预处理 twitter会将动态内容事先转化成静态html
- 有些工作是定制化的，没法预先处理的，怎么办？
“The frontend, which constantly checks for new “job is done” - signals, sees that the job was done and informs the user about it” 前端要检查，如果好了通知客户
RabbitMQ
就是排队技术，每个task在队列里面
对提升用户体验很好，比如Leetcode的设计