6大原则总结

Vertical Scalability 更强的cpu，比如之前在连连，加密机能力不够，后来直接将4c8g改为16c32g，一举解决了问题，这个方式最快，但是有天花板，不能无限用Horizonal Scalability 横向扩展，加机器，原则是应用服务器要是无状态的，见如下Caching 互联网是读多写少，一些不怎么变化的信息要缓存起来，甚至twitter会将动态内容事先转化成静态html，和如下第5条相关Load Balancing 负载均衡，和横向扩展相关联DB replication 主从结构，互联网是读多写少，读都是分开读DB partition 就是分库分表

Scalability for dummies -1

Clone（其实就是横向扩展）

应用服务器不能存储用户session信息，也不能存储profile信息，总之这个信息是无状态的，这样某台挂了后，很容易切到另外一台

Scalability for dummies -2

Nosql insteadOf mysql

第一章讲到clone人的进攻，因为无状态，且不是垂直扩展，所以横向扩展是没问题，不会有天花板，但是体系内的其他成了短板 比如数据库

第一条路是 分库分表 sql调优，但是作者建议在规模不可控制前，一开始就nosql之所以nosql是因为互联网的数据特征，比如音频文件，视频文件，图片文件，这种用nosql好很多 但是要注意，如果有很多关联查询（select a., b. from TableA, TableB where a.id = b.id）那又很慢了

Scalability for dummies -3

用好Cache！用内存的高速性（比如redis）代替磁盘的缓慢性

缓存查询结果，但是容易有过期的问题（不建议）缓存对象，这也是圈圈目前在用的 文章中建议了一种更加异步的方式，所以请求都访问redis，背后是一组worker线程，不停地将数据从数据库搬运到redis（也就是应用服务器不直接访问数据库） 哪些对象适合缓存用户session热点博客用户和朋友的关系热门视频

Scalability for dummies -4

预处理 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的设计