技术

第四章：数据编码与演化 应用程序总是增增改改。 修改程序大多数情况下也在修改存储的数据。 关系数据库通常假定数据库中的所有数据都遵循一个模式：尽管可以更改该模式（通过模式迁移，即ALTER语句），但是在任何时间点都有且仅有一个正确的模式。 ...

第三章：存储与检索 本章介绍了传统关系型数据库与“NoSQL”数据库的存储引擎。 我们会研究两大类存储引擎：日志结构（log-structured） 的存储引擎，以及面向页面（page-oriented） 的存储引擎（例如B树）。 ...

第二章：数据模型与查询语言 数据模型可能是软件开发中最重要的部分了，因为它们的影响如此深远：不仅仅影响着软件的编写方式，而且影响着我们的解题思路。 一个复杂的应用程序可能会有更多的中间层次，比如基于API的API，不过基本思想仍然是一样的：每个层都通过提供一个明确的数据模型来隐藏更低层次中的复杂性。这些抽象允许不同的人群有效地协作。 ...

第一章：可靠性，可扩展性，可维护性 关于数据系统的思考 单个工具已经不能满足应用系统的需求，总体工作被拆分成一系列能被单个工具高效完成的任务，并通过应用代码将它们缝合起来。比如一个缓存、索引、数据库协作的例子： ...

推荐序 这本书的适合所有后台开发工程师、大数据工程师，也很适合面试前复习系统设计的同学。 什么是「数据密集型应用系统」？ 当数据（数据量、数据复杂度、数据变化速度）是一个应用的主要挑战，那么可以把这个应用称为数据密集型的。与之相对的是计算密集型——处理器速度是主要瓶颈。 ...

分布式系统秒杀交易性能优化 1、背景 首先介绍一下这个交易的功能： 该交易是一个定期存款交易，利率非常高，存期有三个月，六个月、一年、两年、三年、五年，年化利率基本上每天发布的产品中都有4%以上的。其中六个月和一年的年化利率最受欢迎。这个定期产品只能每天9点开始购买，并且支持的渠道只有手机银行，因此在每天8点59-9点这个区间会收到非常的请求。根据指标控制中心查询的数据大概在9点到9点01秒这一秒中大概需要处理1000个请求。不过老核心那边怕给系统搞宕机做了一个并发控制，也就是达到性能瓶颈时会限制购买，打印“系统繁忙”反馈给前端.大概在不久前，老核心反馈给我们分布式核心说该交易也还需要持续进行优化，因为目前该产品实在是太火爆了，导致老核心也一直无法处理短时间内的大量请求，只能反馈系统繁忙。 ...

最近在看《重构》第二版，看到替换循环这里，想到我在工作中也是无脑的使用循环和if-else，最近也有空没事就重构之前自己写的代码以及别人留下来的代码。因此就自己尝试了一下管道。发现确实非常的简单明了。大致我举个例子说明下： ...

这几天一直在修并行环境的bug，也踩了不少坑， 记录一下 1、关于对集合的排序循环问题。集合被修改之后不能再用于循环 原本的逻辑是这样的，在对C代码使用Java进行翻写的时候，因为C使用的是临时表，我这边用的是List集合，然后那边直接order By，而我用的是封装的一个对集合进行排序的方法。因此该集合在某种程度上是被修改了的，但是我仍然对让它进入了下一次循环，而没有break掉，或者使用一个新的集合来进行修改，导致并行生产环境报错。在不确定集合是否被修改的情况下，一定要New一个新的List来进行修改，保持原来的List进行循环。。。。 ...

进程的概念 在多道程序环境下，允许多个程序并发执行，此时他们将失去封闭性，并具有间断性和不可再现性的特征。为此引入了进程的概念，以便更好地描述和控制程序的并发执行，实现操作系统的并发行和共享性。为此引入了进程的概念，以便更好地描述和控制程序的并发执行，实现操作系统的并发性和共享性。 ...

有效数据生成以及插入数据库方案 先产生insert数据并存到备份文件中 因为有效数据生成的数量不大， 按照压测那边给我的需求大概每个交易4千笔数据左右，需要并发量比较高的交易也不过4万笔数据，涉及到转账的交易数据量比较高一点。并且需要做一个备份为了以后压测可以备用，因此我选择先生成到不同的表对应的表名文件中，然后再写一个批量执行SQL的程序执行这些文件中的insert语句 ...