《design data-intensive application》阅读笔记之一

于2017年末得知了一本神书《design data-intensive application》，读完即可惜，如果早拿到这本书，就不会纠结于很多分布式系统和数据库的书了。因为已通读完全书，觉得如果不写

一些东西，确实可惜了。希望中文版早日出来吧。

如果我们要设计一个data system，有什么是我们需要考虑的呢？

首先，应该是存储数据的database。且不论这些怎么存储，假设是一个txt文档。当这个txt文档数据量很小时，一眼就能看出我们需要的数据在哪了。当数据量随之增长时，眼睛就不够用了，

我们需要区分经常读取的数据(hot spot)和不怎么读取的数据，这部分经常读的数据，不可能存放在很慢的磁盘上了，每次读取都去需要全量加载，而是直接缓存放入内存，这就是cache。那么

突发紧急情况，我们又想读取那些老旧的数据，这部分数据肯定不会是存放在内存里，那么这时候我们就需要一个index去filter or search by keyword。除此之外，我们不会局限于这部分数据

我们还需要和其他的process交流，那么所谓的batch process和stream process应运而生。于是一个简单的data system诞生了。

可能我们在app上，我们会觉得我们只是按下一个按钮，但是仅仅是一个简单的data system，就已经如此让人惊叹了。对的，这仅仅只是一个简单的抽象，实际上，我们需要考虑如何保证

client看到的cache和stored data是一致的？如何确保某一台机器坏了，系统还能正常用？好了，你的boss突然想撒钱了，贪小便宜的client会使得你的系统load不断增长，这时你该如何保证？

不仅如此，client可不能忍受打开网页相应的缓慢，performance可不能放弃了。当然，还有各种各样神奇的问题在等着你。

不过在此书当中，抽象了三个factor去描述这些事。如下

一.reliability 系统应该持续工作，在正确的时间执行正确的事。这可不是一件容易的事

1.hardware fault

首先我们不应该保证我们的电脑随时随地都是可work的，我们会遇上hard disk crash、RAM becomes faulty、the power grid has a blackout等等，不要以为这些乱七八糟的不会发生

在一个拥有很多太机器的data center，这些是家常便饭。

2.software Errors

这个可能会是software bug（不局限于你写的程序，也有可能是系统的bug或者是某个不合常理的input），shared resource的失效（比如线程的共享内存），某个系统依赖的something

变慢了，甚至失去联系等等

3.Human Errors

这个呢，毕竟程序员也是人，bug不可避免。测试的重要性也在此得到了体现。

二.scalable 随着系统volume的增长，处理事情的能力也应该随之增长

这个不是我加机器就能是的系统的处理能力就能增长的。有两个东西需要考虑，describing load 这个决定着系统该如何设计。书中举了微博为例，当一个普通用户使用时，设计了一个

良好的关系模型，但是这个用户是某个名人时，那就需要使用消息分发了。describing performance 在batch process，考虑的应该是throughput。但是在online system，response time

就很重要了，而这个需要考虑到GC pause、TCP retransmission、the loss of network packet。。。

三.maintainability 系统应该设计的给人用的，而不是电脑。

这个估计很多程序员都会碰到，一个乱七八糟的legacy system，足够让人喝一壶了。评判标准很简单，可操作，简单，兼容。