Resiliency：可译为容错性，强调从错误状态恢复的能力。形容词Resilient可译作“可容错的”。
Elasticity：可译为伸缩性，强调根据负载进行水平伸缩的能力。形容词Elastic可译作“可伸缩的”。
Elasticity（可伸缩性）：指系统在流量大时能横向扩展，当流量小时又能减少不必要的资源；（https://stackoverflow.com/questions/9587919/what-is-the-difference-between-scalability-and-elasticity）Scalability（可扩放性、可扩展性？、可拓展性？）：指系统面对流量压力可以让硬件更强的纵向扩展（scale up）或新增节点的横向扩展(scale out)；Resilience（系统回弹性）：来源于Resilience Engineering，指系统不仅能够从威胁和压力中恢复过来，而且能够在各种条件下根据需要来运转，并且能适当地应对那些干扰和机遇。（http://erikhollnagel.com/ideas/resilience-engineering.html）
horizon/vertical scale
elastic侧重于易伸缩，所以elastic的东西都是橡皮筋、松紧带、弹性纤维，这类可以“蹦大缩小，拉长缩短”的东西；这个词的关键在于--->>“伸缩”，
flexible侧重于易弯曲，所以flexible的东西都是什么电缆、软管、胶铜线，这类可以“扭来扭去，弯来绕去”的东西；这个词的关键在于--->>“弯曲、扭曲”
resilient侧重于可恢复、可回复，所以resilient的东西都是什么沙发、席梦思、柔嫩的肌肤，这些"坐下去、按下去，会弹起来"的东西；这个词的关键在于--->>“回复、复苏”
Resilient是有韧性，elastic是有弹性。一根弹簧压得很用力很长时间放开之后仍然能够恢复到原有长度叫有韧性，一根弹簧能拉很大也能压到很小叫有弹性。你程序出错了能马上恢复过来叫有韧性，你程序处理能力能大能小叫有弹性。你跌倒了能马上站起来叫有韧性，你能适应不同环境叫有弹性。你在对抗敌人攻击的时候需要有韧性，在和人谈合作的时候需要有弹性。
Sharding and Quorum
Distributed systems often have to store a lot more data, than a single node can do so. So how does one go about storing a bunch of data on a certain number of machines?
Why did idempotency matter when building a large payments system? Most importantly: to avoid double charges or double refunds. Given that our messaging system has at least once, lossless delivery, we need to assume that all messages might be delivered multiple times and systems need to ensure idempotency. We chose to handle this with versioning and optimistic locking, having the sytems that implement idempotent behaviour use a strongly consistent store as their data source.
Let's say we intend to implement idempotency by having optimistic locking in place, to avoid concurrent updates. In order to have optimistic locking, the system needs to be strongly consistent - so that at the time of the operation, we can check if another operation has been initiated, using some sort of versioning.
The idea behind idempotency is merely that the change involved should not be a direct effect of the GET request itself.
Data Durability
Why did data durability matter when building a payments system? For many parts of the system, no data could be lost, given this being something critical, like payments. The distributed data stores we built on needed to support cluster level data durability - so even if instances would crash, completed transactions would persist. These days, most distributed data storage services, like Cassandra, MongoDB, HDFS or Dynamodb all support durability at various levels and can be all configured to provide cluster level durability.
Message Persistence and Durability
However, building a system that delivers each message exactly once or one that delivers at least once is different complexity. We decided to implement a durable messaging system with at least once delivery and chose a messaging bus, on top of which we would build this (we ended up going with Kafka, setting up a lossless cluster for this case).
Consistency is a concept that I spent the most time understanding and appreciating. There are several consistency models, the most common one used in distributed systems being strong consistency, weak consistency and eventual consistency. The Hackernoon article on eventual vs strong consistency gives a nice and practical overview of what the tradeoffs between these models are. Typically, the weaker the consistency required, the faster the system can be, but the more likely it will return not the latest set of data.
关系型数据库的操作通常采用 ORM 库，将表格转换成对象。ORM 主要分成两种类型：Active Record 与 Data Mapper。本文讨论这两种模型的差异和适用场景。
要解决冲突，一种办法是是锁，即基于锁的并发控制，比如2PL，这种方式开销比较高，而且无法避免死锁。多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 这样在读操作不用阻塞写操作，写操作不用阻塞读操作的同时，避免了脏读和不可重复读乐观并发控制（OCC）是一种用来解决写-写冲突的无锁并发控制，认为事务间争用没有那么多，所以先进行修改，在提交事务前，检查一下事务开始后，有没有新提交改变，如果没有就提交，如果有就放弃并重试。乐观并发控制类似自选锁。乐观并发控制适用于低数据争用，写冲突比较少的环境。多版本并发控制可以结合基于锁的并发控制来解决写-写冲突，即MVCC+2PL，也可以结合乐观并发控制来解决写-写冲突。
MVCC解决的问题是读写互相不阻塞的问题，每次更新都产生一个新的版本，读的话可以读历史版本。试想，如果一个数据只有一个版本，那么多个事务对这个数据进行读写是不是需要读写锁来保护? 一个读写事务在运行的过程中在访问数据之前先加读/写锁这种实现叫做悲观锁，悲观体现在，先加锁，独占数据，防止别人加锁。乐观锁呢，读写事务，在真正的提交之前，不加读/写锁，而是先看一下数据的版本/时间戳，等到真正提交的时候再看一下版本/时间戳，如果两次相同，说明别人期间没有对数据进行过修改，那么就可以放心提交。乐观体现在，访问数据时不提前加锁。在资源冲突不激烈的场合，用乐观锁性能较好。如果资源冲突严重，乐观锁的实现会导致事务提交的时候经常看到别人在他之前已经修改了数据，然后要进行回滚或者重试，还不如一上来就加锁。