高并发系统设计(1)—

原本想聊下缓存的相关技术，但是纯聊缓存未免眼界太窄，视野太小，既然打算写一个系列，不如就先从底层聊起，然后慢慢铺开。本篇先聊分级存储引入的问题，以及对服务和架构的影响：服务分类、分层架构（服务分层）。

了解计算机组成的都知道，存储结构是分层（级）的，到底是什么原因呢？

用户期望提供尽可能高的存取速度和尽量大的存储容量，但价格尽可能低。矛盾的现实是：

计算机发挥性能要求存储存取速度与CPU相匹配。离 CPU 越近的存储，速度越快，成本越高，容量也因此越小。

数据从产生的那一刻起就自然地进入到了一个循环，经过创建、访问、迁移、归档和销毁，最终完成一个生命周期，而这个过程必然需要良好的管理，否则，要么是浪费了过多的资源；要么是资源不足降低了工作效率。

数据生来并非平等的。不同的数据具有不同的价值，如业务生产相关的关键数据和日志；同一数据在其不同阶段价值也不一样。纵向来看，即访问越多，其价值越高。

分级存储，利用了数据访问的局部性原理，使用快速的存储，存储访问最多的数据。当访问数据时，先从内存中取，如果内存中没有，再从磁盘读入内存。以后访问该区域的数据时，就不用再从磁盘读取，因此上层的存储都可以认为是下层的缓存。

总结一下：局部性原理的缓存体系，平衡了速度和价格的矛盾。

分级存储并非是解决问题的银弹，解决了矛盾的同时，也给存储本身引入了一些问题：

命中率

当数据被上层存储覆盖时，一切尽在掌握，分层存储的机制可以正常的工作。当热点数据穿透上层落到下层时，下层存储的性能将成为整体的瓶颈。
一致性

作为缓存，上层存储在提高系统处理性能的同时，也可能会“滞留”IO操作。如果在系统发生故障时，仍有部分IO“滞留”，真正写到下层存储的数据就会少于服务实际写出的数据，导致数据不一致。
存储管理

由于存在多个层级，数据在生命周期内就需要在不同层级间流动迁移。不同层级需要合适的迁移淘汰策略，满足业务场景的需求。缓存需要缓存策略；内存需要内存管理策略；磁盘需要磁盘管理策略。

如同放洗澡水一样，首先检查热水多热，然后检查冷水多冷。然后调节水龙头旋钮，以流出温度合适的水。

类似的，基于不同类型存储访问速度的巨大差异，需要关注的重点不同。多级存储也给架构设计带来不少问题。

在大型互联网公司，所有的服务被分为三种类型：

CPU消耗型：也称为“计算密集型”，指服务使用CPU完成计算任务，受CPU速度限制。_CPU越快，任务处理越快。_
内存消耗型：也称为“内存密集型”，指服务执行任务过程中受内存大小和访问速度限制。_内存越大、访问速度越快，任务处理速度越快。_ 通常为搜索类、缓存类、内存数据库等需求大量内存的服务
I/O消耗型：也称为“I/O密集型”，指服务执行任务涉及到大量的网络传输或磁盘I/O，受I/O速度限制。_I/O越快，任务处理越快。_ 一旦发生I/O，服务的工作线程(进程)就会处于等待状态，当I/O结束，数据准备好后，线程(进程)才会继续执行。

一个服务可以既是“CPU消耗型“，同时也是“内存消耗型”，例如：搜索服务 —— 烧钱玩意儿，腾讯卖掉搜索给搜狗估计也是被烧的肉疼了吧：）。

那为什么如此划分呢？

盘点下业界在高并发场景下，使用的存储方案(至少保证数据不丢失)：

纯内存数据库：以 mongodb 为代表。成本高昂
内存数据库 + 磁盘数据库：以 Redis/memcached + 2. Mysql/TiDB 为代表。使用起来比较复杂，需要业务自己处理分级存储带来的问题
高性能高可用分布式数据库：以 megastore（谷歌）/ paxosstore(微信) / Dynamo (亚马逊)，技术门槛比较高，大厂专属

可以看到绝大部分的互联网公司，还是依靠第二种方案扛住高并发的请求。那么应对高并发的架构中，就不能缺少存储层（也可以称为：持久层，数据访问层），否则业务代码会与存储管理的代码交叉耦合在一起

使用第二种方案，就免不了缓存的是是非非。既然缓存也是存储层级中的一层，所有的问题也就脱不开分级问题的范畴了，后续详聊。

参考链接：

高并发系统设计(1)——分级存储