1
2

文章作者:lday
原始链接:http://lday.me/2017/02/01/0003_seri-stm-etcd3/

本文翻译自Serializability and Distributed Software Transactional Memory with etcd3

新的etcd3 API引入了新的更加强大的原语，相比较于etcd2的限制，这些新的原语充分利用了系统的能力。作为评估etcd3性能的一部分，我们花费了很大力气来使用新的API开发分布式的并发算法。

etcd3的访问序列化要优于etcd2的隔离模型。当应用更新若干个相关的key时，通常需要这些更新要么全部成功，要么全部失败，进而维持应用程序数据的一致性。在实际应用中，etcd3的事务操作和它的多修订版本数据存储给予了etcd一种用于表达原子性的方式，这种原子性基于对多次修订的序列化。在etcd2上，每一个key的更新是独立提交到数据存储上的；这样就无法做到整个提交的原子性。为了评判etcd3的原语是否正确以及性能情况，我们实现了通用的分布式同步控制“食谱”，并进行了基准测试。

这篇文章关注于etcd3新的最小事务接口所提供的原子性。我们将涵盖etcd3的事务，并且演示通过事务来实现原子更新。接着，我们将通过概要介绍一个简单的客户端侧软事务实现来展示etcd的修订元数据如何自然的映射到软事务内存（STM）上。最后，我们将说明这种软事务内存实现是分布式共享锁的一种高性能替代。

牛津大学图书馆的噪音，用于工作和居家环境很不错：

GFS MapReduce BigTable关系

GFS（2003年发表）使用商用硬件集群存储海量数据。文件系统将数据在节点之间冗余复制。MapReduce（2004）是GFS架构的一个补充，因为它能够充分利用GFS集群中所有低价服务器提供的大量CPU。它与GFS一道形成了处理海量数据的核心力量，包括构建Google的搜索索引。不过这两个系统都缺乏实时随机存取数据的能力，意味着尚不足以处理Web服务。

GFS的另一个缺陷就是，它适合存储少许非常非常大的文件，而不适合存储成千数万的小文件，例如社交平台上的图片，因为文件的无数据信息最终要存储在主节点的内存中，文件越多master的压力越大。

这时候需要一个能够驱动交互应用的解决方案，且能够同时利用以上两种基础架构和依靠GFS 存储的数据冗余和数据可用性较强的特点。存储的数据应该拆分成特别小的条目，然后由系统将这些小记录聚合到非常大的文件中，并提供一些索引排序，让用户可以查找最少的磁盘就能够获取到数据。最终，它要能够及时存储爬虫的结果，并跟MapReduce协作生成搜索索引。于是考虑放弃关系型的特点，采用简单的API来进行增删改查操作，另加一个扫描函数，以在较大的键范围或全表上迭代扫描，最终形成一个管理结构化数据的分布式存储系统BigTable（2006）。

值得一提的是CAP定理，当中指出，一个分布式系统只能同时实现一致性、可用性和分区容忍性（独立性）中的两个，不可能三者兼顾。放宽一致性的要求会提升系统的可用性。

————————————————
版权声明：本文为CSDN博主「hennybatter」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012135300/article/details/51023145

inline这个属性，应该是默认的，为什么这么说，这个属性用作嵌套结构体内，消除嵌套结构体的层级关系，将其转为一个层级。

结构体的数据是{"user_id": 344, "user_name": "shiki"}。

下面给出的user_id是int，json使用string类型去接数据会报错。

从嵌入式转入互联网圈子快一年多了，感觉还是有些要死不活，当初网上探不到路的感觉却是消失了不少，发现不是技术栈有问题，还是自身出了问题，毕竟每个人都在前进，不管是有人引领还是盲人探路，其实都是沉下心来去安心做点什么。有些时候，我们不是对这个技术的浮躁，而是对我们沉不下来学这个技术浮躁。