转载

人人都想学架构（三）

本文是《从0开始学架构》专栏学习的第三篇，第四节和第五节分别说了存储高性能和计算高性能。

第四节主要说的是存储高性能，研究的课题就是MySQL这样的关系型数据库，NoSQL，缓存。

（一）MySQL

对于关系型数据库来说，比较熟悉的就是MySQL，如果将所有的读取压力全部放在单一的节点上，那肯定是慢的，所以我们可以基于主从和主备的机制进行 读写分离 。

理论上主备中的备是做数据冷备的，不提供在线访问；而主从的从才真正用于读写分离，分担主的压力；在实践中，主备的备也用于线上服务，所以主从和主备可以认为是一样的，主用于数据更新，从（备）用于查询，这样能够提高查询性能。

可主从和主备肯定会遇到同步延迟的问题，延迟一方面是MySQL同步机制导致的，另外是数据应用不当造成的，根据 我的经验 ，大部分延迟是因为在数据库上做了大量复杂SQL的查询。

如果确实出现延迟，那么应用就要有一些策略，比如：

写操作后，特定时间内查询主库，比较难控制，代码会显得很难看。
二次读取，现实中很难实施，因为你怎么知道副库延迟了？

如果确定知道延迟了，那么二次可以读取主库。
关键业务读取主库，非关键业务采取读写分离。

第二个优化MySQL存储性能的方法就是 分库分表 ，读写分离分散了读写操作的压力，但没有分散存储压力，尤其数据量超大的时候，查询性能就会低下了，解决方法就是拆分。

分库一般是基于业务来分，但这样也不一定解决问题，比如某个业务即使分库后，单库存储量还是非常大，这时候就要选择分表了，分表分为垂直发表和水平分表。

比如新浪博客的博文表垂直分为索引表和内容表，索引表和内容表结合起来才是博文数据，考虑到内容字段非常大，所以垂直拆分是合适的，因为索引表变得非常小，而它的查询频率很高，相应查询性能就比较高了。

就算垂直分表后，单表的记录可能还是会非常大，这时候就要水平分表了，比如某个人的博文数据在一张表，另外个人的博文数据在另外一张表。

水平分表比垂直分表引入更多的复杂性，主要就是路由策略，可以采取Hash路由的方式，也可以采用路由表的方式，Hash路由相对还是很均衡的，但如果将来要再拆分，就要重新导入导出数据了；而路由表的方式除了影响性能，本身还可能遇到瓶颈和可用性问题，优势是将来再拆分就比较方便了。就 我的经验 ，还是采用Hash路由方式更简单，另外也不要迷信分库分表，MySQL的性能其实没有那么脆弱。

分库分表劣势在于将同一份数据拆成多份了，这样就无法使用很多SQL功能，比如join，count，order by等SQL就用不了了，事务也完成不了了，只能采取和分布式系统一样的事务解决方案了。

读写分离、路由策略、负载均衡、连接池，很多中间件支持这些功能，但不知道有没有大型公司使用，引入中间件可能会带来新问题，数据库中间件可能能锦上添花，但优秀的MySQL管理机制不一定要通过中间件来完成，规约也是很好的方式。

（二）NoSQL

除了MySQL外，现在流行的还有NoSQL系统，MySQL和NoSQL本质上是完全不同的模型，所以最好不要强行比较，双方各有自己的应用场景，应该互相补充。

NoSQL系统对于理解分布式系统非常有好处，有很多类型的软件，这个专栏也是点到为止，我建议找其他资料进一步学习，如果是初学，可以了解下不同NoSQL系统适用的场景。

选型NoSQL和Mysql的时候，考虑几个指标，数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等，根据这些指标分为：

管理型系统，如运营类系统，首选关系型。
大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型。
日志型系统，原始数据选列式，日志搜索选倒排索引。
搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引。
事务型系统，如库存、交易、记账，选关系型+缓存+一致性协议，或新型关系数据库。
离线计算，如大量数据分析，首选列式，关系型也可以。
实时计算，如实时监控，可以选时序数据库，或列式数据库。

从上面看出，Nosql主要分为四种：

K-V 存储：

解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
文档数据库：

解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
列式数据库：

解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
全文搜索引擎：

解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

除了HBase以外，其他几种软件都是我要继续加强的。

（三）缓存

缓存无处不在，浏览器缓存，页面缓存，数据缓存，边缘缓存，虚拟内存，寄存器Cache，此处重点介绍数据缓存。

数据缓存原理很简单，选择软件也很简单，作用就是缓解后端压力（一次生成，多次使用），复合结果存储到缓存中（避免复杂运算）。

缓存本身不复杂， 我的经验 是根据业务选择缓存策略，思考该不该缓存，已经使用缓存可能带来的问题。

缓存穿透表示缓存没有发生作用，第一种情况是后端数据即使为空，缓存中也应该设置一个标志位，否则缓存以为没有缓存数据，每次都会重新查询后端。第二种情况没太看明白，意思是一些业务即使使用缓存，但在查询的时候缓存基本上是失效的，还是会查询后端，比如爬虫分页，这种情况即使有缓存设计，但也没有什么用，还多浪费了一次缓存查询，在业务上，如果设计不好或遇到爬虫遍历就会出现这种问题，命中率极低，而且还没有太好的解决方法。 我的经验 ，分页一般第一页使用缓存就可以了。

缓存雪崩表示缓存失效后（比如过期时间一致或某个缓存服务器重启了），多个进程可能会同时更新一个缓存，导致对后端的频繁访问。解决方案是使用分布式锁或后台更新（定时读取，队列通知）。

缓存热点，比如缓存服务器有十个节点，但由于热点集中在一个节点上，这样可能90%的请求落在这个节点上，导致极大的负载，可以通过冗余多份相同数据的节点解决该问题。

我的经验是仔细了解自己的业务，根据缓存软件的特性择决，选择合适的策略去解决业务，这一块其实有很多技巧，但是显得不是那么正规。

第五节介绍了如何让Web服务器性能更好，在单机性能达到极致后，还可以采用集群方案。

（一）单机高性能

1：PPC（Process per Connection）

主进程接收到一个连接后，fork出一个子进程处理请求，一个疑问（子进程响应的时候还要经过主进程吗？），除了fork代价高的问题，主进程和子进程可能还要进行IPC通信。

2：prefork

提前预生成子进程，由子进程accept新连接，Apache prefork采取的就是这种形式，这种方式解决了PPC fork带来的损耗。

3：TPC（Thread per Connection）

创建一个线程处理新连接，线程比进程更轻量，但会存在互斥和共享的问题，可能会出现死锁问题，另外一个线程出现问题可能会导致其他线程退出，稳定性需要注意。

4：prethread