参加公司培训以及和mentor聊天，颇有收获。

系统设计之初进行扁平的设计，然后分模块，分装。

培训进一步了解到了一些概念和业界的作法：

1. 1/0 风险

2. 单点故障

3. 程序对齐

4. 雪崩

5. 重点客户和非重点客户分别处理

6. 核心进程和业务进程分离

随着系统变大，遇到两个方面的问题：

1. 功能变复杂

2. 容量规模变大

应对问题1，正确的观念是：

1. 分业务单元，分模块，分进程

2. 每个模块半天到两天可以读完和接手

3. 并行开发

4. 降低对开发人员的要求

5. 分层设计 改为 平行设计。分层意味着上层对下层的依赖或者相互依赖，在使用分层设计的时候必须考虑是否必要。化繁为简。

应对问题2，正确的观点是：

1. 根据预期最大规模，拆分最小业务单元，单元之间不影响。例如目标用户量在42亿，每10万一个段，共42000段并分布在不同的物理机器上。理解段为最细的粒度，根据机器资源情况来制定段的大小：如每个用户最多给100kb用户数据，内存为1GB。则以10W用户id数位最小业务单元。 和Mongodb的sharding的思想是一致的，mongodb的trunk并不是连续的，从而加快数据迁移的速度。但对路由性能和复杂度有一定影响。

2. hash + 去模的目标是均匀化