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类型去接数据会报错。

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

fsnotify在linux上对文件监听是正常的，对比在windows上，却会出现两次event，这个问题解决方法如下：

go mod 不支持 http 吗？

是的，不支持。但有方法可以迂回。