系统设计中的四个常用战术

系统设计一方面需要实现整个系统的功能性属性，另一方面也需要兼顾系统的非功能属性。比如：性能（比如一秒处理的数据量、单位时间内可接收的请求、响应一个请求需要的最长时间等等）、可维护性（后期是否容易做功能变更）、可用性（单位时间内系统可以提供正常服务的时间）等等。要兼顾好这些非功能属性，结合笔者多年的系统设计经历，有以下四点战术可供参考：

一、冗余

即一份复制多份。通常说的主从库复制、多节点部署都本质上都是一种冗余的手段。将一份数据或进程部署到多个节点上，通过统一的接入层将请求分发到后端多份相同的节点上，达到空间换时间的目的。

冗余可以带来性能上的提升，因为服务的节点多了，查询与相应的速度自然加快了。

但是，冗余也带来了新问题——各节点之间如何保证数据的一致性。这其实又引入了分布式系统中经典的CAP问题，结论为：在网络故障的前提下，只能在一致性与可用性之间选其一。关于CAP问题，可以百度搜索分布式系统CAP，这里就不展开讨论。

二、拆分

拆分包括横向拆分与纵向拆分，既包括数据的拆分也包括服务的拆分。

一般来说，横向分层，纵向分模块。

所谓的横向分层，是指对于一个系统来说，将系统看成一块蛋糕，从上至下划分系统，可以将系统划分成多个层次。一般我们可以划分为接入层、应用层、业务层、存储层等。

纵向分模块，是指将系统看成一个个水平连接的积木，沿着Y轴一刀刀切下去之后，系统会被分为一个个独立的模块。

对于数据而言，其实也可以横向划分或者纵向划分。比如常见的分表：横向划分就是将数据按照一定的hash算法分到不同表中，每个表的结构一样。

纵向划分就是将表的结构拆开，容易变的与不容易变的字段分在不同表中；变长的与定长的分在不同表中。每个表的结构不一样。

三、缓存

使用缓存的最基本假设是：离业务越近的数据读起来越快。

按照这个推论，可以得出：内存>硬盘>网络。

因为，对于数据库来说，我们总会将经常用到的数据（数据库的磁盘上）缓存到业务机器上（内存）。

对于BS或CS架构的应用来说，我们也会将css、js或者一些用户数据缓存到用户的浏览器或者设备端，以提高系统性能。

四、异步计算

异步是相对于同步而言，即对于任何一个请求会马上响应，但是这个响应不代表是否成功，只代表服务收到请求。而真正的业务会通过一种消息队列机制转入异步执行，整个业务看起来是没有在任何环节有等待的流程。

对于非阻塞的场景，在引入异步计算之后，也可以提供系统的吞吐量。

但是，随之也会带来一个问题：异步处理完成的任务如何通知请求方？ 一般的处理方式是轮询或者引入回调机制。

以上就是系统设计中常用的四个战术，他们在性能、可维护性、可用性上都可以带来收益，但是同时也会引入一致性、用户体验等问题。如何使用这些战术，还是要看实际的业务场景。