引言

• 读书是思考的源泉。如何有效思考、高效思考是值得思考的问题。
• 思考的角度对于认识事物、增强分析事物的能力极为重要，如果只是读一些概念性的书籍，并不能够起到很好的促进思考的作用。
• 哲学是万物之源，纷繁复杂的事物追踪到本质总是相同的，而我们又能够从这个相同点出发，用相同的思维方式，分析自己不熟悉的事物。
• 2018年，思考和读书并行，思考比读书要多，无论思考的对与错，都是锻炼思考能力的必经之路。
• 2018年，更加倾向于读一些经济金融类的书籍，一方面是自己感兴趣，另一方面读这些书能够触发自己对社会问题的哲学化分析，认识更加深刻，理解更加透彻，分析更加全面，可能这就是进步吧。
• 如果您也对下列书籍感兴趣，欢迎和我讨论。

2018-我的书单

非理性繁荣 【美】罗伯特·J·希勒

• 对于一个经济体，繁荣总是好事，但作者却不这么认为，作者眼中的繁荣大多是非理性的，繁荣的背后总是隐藏着危机和焦虑；
• 世界主要经济体不断规律性的发生金融危机，这背后的原因没人说得清，作者认为这种危机正是非理性繁荣中潜藏危机的集中爆发；
• 作者阐释了政府在市场调节中的独特作用，认为政府应当在经济繁荣且过热时泼一盆冷水，去除高风险因素，促使经济和市场的理性发展；
• 作者自始至终也没有对这种非理性繁荣给出正确或是错误的评价，也许市场本身就是非理性的，无需过多解释。

失去的二十年 【日】池田信夫

• 日本自和美国签订广场协议之后，经济一直低迷，随着日本央行不断加息，房地产泡沫随之破灭，之后是长达十几年的低沉和萧条期，就算是现在，日本仍然没有摆脱经济乏力的困局，甚至进入了低欲望社会，叠加上老龄化的影响，日本经济堪忧；
• 作者是日本著名经济学家，从理论和实践两个方面阐述了自己对于日本经济倒退的思考；
• 作者并不认为广场协议是日本经济倒退的元凶，真正的原因是日本没有抓住互联网产业革命，错失发展良机，企业死守传统产品线和营销模式，没有主动发掘和创造用户需求，使日本在国际竞争中逐步失去原先保有的制造业优势；
• 作者同时认为民粹主义是日本经济缺乏活力和改革勇气的重要原因。

泡沫经济学 【日】野口悠纪雄

• 经济泡沫是如何产生的？本书给出了最好的回答。泡沫的产生并非一朝一夕，也并未通货膨胀那么简单；
• 人们对于一个事物的价值的认识和其实际价值产生了偏差，就会引起泡沫，这种泡沫通过资本市场的自由交易被成倍放大，最终变得不可收拾；
• 泡沫并不可怕，可怕的是没有人能够控制泡沫的增长，谁也不知道泡沫何时会破裂；
• 日本房地产泡沫就是在日本央行不断加息下终于破裂，造成了经济的大萧条和衰退，长达十年之久；
• 日本的经验教训很值得我们研究和学习，如何准确评估和妥善管控金融风险，是每个国家必须面临的重要课题。

今日简史 【以】尤瓦尔·赫拉利

• 这是一本写未来的书；
• 未来会是什么样？作者列出了若干他认为有极大可能占据我们生活大部分的事物和技术：人工智能，基因工程，量子理论等；
• 没有人能够100%的预测未来，但是在未来，如果机器人发展为具有高级智能的机器，人类的命运将何去何从？人存在的意义又是否会发生变化？
• 作者认为未来社会的基础架构、金融体系、信用体系、生活方方面面都将建立在机器和智能的基础上，但能否真正实现还需要时间的检验。

区块链-从数字货币到信用社会 【中】长铗/韩锋

• 区块链应该是2018年最火的话题之一；
• 本书从货币的起源、区块链技术、比特币和挖矿、信用体系建设等方面全方位介绍了区块链的由来、使用，介绍了比特币等电子货币的潜在价值；
• 需要注意的是，电子货币和货币电子化是两个完全不同的概念，前者指的是电子化的通货，后者指的是将纸质货币电子化，以满足交易效率的需要；
• 区块链并不是银弹，区块链在授信、认证和不可篡改方面具有优势的同时，也具有记账速度慢等缺点，区块链不是万能的，用在合适的地方就好；
• 比特币作为一种电子货币，短期内不可能挑战国家法定货币的地位，其币值的不确定性、不可作为宏观调控工具等因素决定了比特币的局限性地位，最近比特币价值跌得厉害，比特币作为一种投资品具有极高的风险。

量子宇宙 【英】布莱恩·克劳斯 /【英】杰夫·福修

• 量子作为当今社会最神秘莫测的事物，吸引了很多人的目光；
• 本书作者用尽量易懂的语言，讲述了量子具有的很多其特性值，比如波粒二象性、不确定性，对量子的质量、能量、自旋、电荷等属性也加以描述；
• 量子论作为物理学中唯一能够和相对论相提并论的理论，受到人们的广泛关注；
• 研究量子能否让我们了解宇宙的终极秘密还不得而知，但是量子计算机、量子通信已经呼之欲出，人们可以利用量子的性质，大幅提升计算机的运算速度和通信传输的保密程度。

思考快与慢 【美】丹尼尔·卡尼曼

• 作者可谓是思考的专家；
• 作者提出了思考的两个维度：快的维度，即用感性去思考，慢的维度，即用理性去思考；
• 作者不否定任何一个维度的思考，认为两者都有其重要作用和价值；
• 作者指出，有时候人无意识的总是用快的维度去思考问题，殊不知在重要的问题上，这种思维方式会造成很坏的影响，正确的方法是，停止思考，并有意识的用慢的维度重新开始思考，以获取正确和客观的结果。

小岛经济学 【美】彼得·希夫 /【美】安德鲁·希夫

• 本书的作者深谙经济内在的运行规律，他将这种规律描述写的浅显易懂，便于大家理解；
• 作者将一个小岛上的居民比作一个经济体，对物物交换、货币的产生、资本的产生、公司的产生、价值链的维护、股票市场的产生、投资属性的产生等一一做了解答，并且和这个小岛上发生的各种金融现象进行完美匹配，用最少的语言，解释了最为复杂的金融现象，令人印象深刻；
• 作者通过暗喻的方式，将小岛比喻成现实世界中的一个个国家，通过小岛间的经贸往来和经贸冲突，完美再现当今世界存在的合作、冲突、利益博弈的全过程，非常值得思考；
• 作者将经济需求和人的需求联系起来，揭示经济运行的本质规律。

引言

• 本文介绍数据库中的旁路缓存策略；

旁路缓存策略

• 旁路缓存策略（cache aside pattern）是一种数据库结合缓存的设计模式；
• 基本架构：
  • 数据库有主数据库（用于写）、从数据库（用于读），另有缓存用于提升读写效率；

策略概述

• 读请求：
  • 先读缓存，如果不命中，再读从数据库；
  • 如果缓存不命中，读从数据库后，写入缓存，方便下次命中；
• 写请求：
  • 先写主数据库，再淘汰缓存；原因：数据总是以数据库为准，而不是以缓存为准，先写作为标准的一方；
  • 淘汰缓存，而不是更新缓存；原因：如果更新而不淘汰缓存，则A\B两个进程并行写时，A写主数据库->B写主数据库->B更新缓存->A更新缓存，则业务期望的缓存为B写入的，但事实缓存中留存A写入的；

存在的问题

• 由于主数据库和从数据库不能及时同步，且读请求总是从从数据库中读并更新缓存，导致缓存始终和从数据库一致，即缓存旧数据的时候，主数据库已经是新数据了；
• 解决方案：当主数据库同步到从数据库时，清除缓存。

引言

• 本文介绍数据库中的架构设计；
• 通常，单机是无法满足大系统对数据库的读写要求的，必须用集群的方式来解决；
• 引入集群意味着提升了系统的复杂度，使系统变得复杂和不好维护；
• 通常采用数据库负载均衡策略、读写分离策略、分库分表策略等加以优化；

负载均衡

• 扩展性强：当系统要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展；
• 可维护性：当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作；
• 安全性：
  • 因为数据会同步的多台服务器上，可以实现数据集的冗余，通过多份数据来保证安全性；
  • 将数据库放到了内网之中，更好地保护了数据库的安全性；
• 易用性：对应用来说完全透明，集群暴露出来的就是一个IP(1) 不能够按照Web服务器的处理能力分配负载；
• 缺点：负载均衡器(控制端)故障，会导致整个数据库系统瘫痪；

读写分离

• 当读和写的频率相差很多时（ebay的读写比率是260:1），为了提升效率，减少磁盘IO压力，采取读写分离；
• 实现原理：
  • 数据库服务器搭建主从集群，一主一从、一主多从都可以；
  • 数据库主机负责读写操作，从机只负责读操作；
  • 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据；
  • 业务服务器将写操作发给数据库主机，将读操作发给数据库从机；

• 主从机数据不一致的解决：

  • 数据不一致：当数据写入主服务器后，要在下次同步后才能查询到；
  • 读从机失败后再读一次主机；

  • 关键业务(账号、转账等)读写操作全部指向主机，非关键业务采用读写分离；

    

分库分表

分数据库

• 是指按功能模块拆分到不同的数据库，比如分为订单库、商品库、用户库；
• join只适用于同一数据库的不同表联合查询，拆分后不同数据库之间无法用join语句进行查询，只能分几次查询；
• 事务是同一数据库中的概念，要想在不同数据库之间实现事务的回滚，只能用查询log回滚的方式；
• 成本高，拆分到不同的数据库意味着需要建立多个备份数据库；

分数据库表 - 垂直(纵向)拆分

• 原先是一个表中包含所有10个字段；
• 现在将查询频率特别高的字段分离到另外的表中（比如婚恋网站的name, sex, age三个字段），其他字段（如个人介绍destribution等）留在原表；
• 优点：查询性能提升，如果只查询重要字段，无需将其他字段也查出来，速度很快；
• 缺点：如果要查出所有字段，必须经过两次查询；

分数据库表 - 水平(横向)拆分

• 将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同；
• 顺序路由：
  • 如可以按订单的日前按年份才分，2003年的放在db1中，2004年的db2,以此类推；
  • 缺点是数据分布不均，可能2003年的订单有100W，2008年的有500W；
• hash路由：
  • 对user_id进行hash（或者如果user_id是数值型的话直接使用user_id的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，决定存在哪个表中；
  • 如果现在想将4个表变成5个表，改变膜值，则所有的数据都需要改变位置，很麻烦；
• 配置路由：
  • 就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作；
  • 优点：灵活性强，一对一关系；
  • 缺点：每次查询之前都要多一次查询，会造成一定的性能损失；

引言

• 本文介绍微服务架构。

微服务特点

• 对服务来说：
  • 服务小，松耦合：服务面向一个独立的业务逻辑，SOA（service oriented architecture）；
  • 独立的进程；
  • 轻量级通信：用https协议通信，用json数据格式；
• 对团队来说：
  • 独立开发：不同团队无需相同技术栈，每个团队维护自己的数据源；
  • 独立部署：不需要过多协调不同团队进度；
  • 康威法则：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构；
• 弊端：
  • 技术栈众多；
  • 分布式系统，数据只能保证最终一致；
  • 运维和测试复杂；

实践建议

• 何时使用：
  • 系统复杂性较低时不使用微服务，使用单块应用，因为微服务所需的基础设施成本高，业务不复杂时微服务的优势无法体现出来；
  • 系统复杂性提升时，逐步将单块应用拆解为微服务；
• 拆分粒度：
  • 微服务拆分粒度过粗，则体现不出微服务的价值；
  • 拆分过细又导致：维护、测试成本上升，效率下降；服务调用链太长，问题定位不方便，性能也会下降；
  • 一般一个微服务由2-3个人负责最为合适；每个人能够全面理解系统；能够相互讨论避免出错；
• 自动化：
  • 随着微服务的增多，自动化工具必须提供，否则维护成本太高；

如何拆分

• 根据业务逻辑拆分；
• 根据服务成熟度拆分：成熟服务，可能会变化的服务；
• 根据可靠性需求拆分：必须保证99.999%可靠的核心服务，保证99%可靠就可以的非核心服务；
• 根据性能需求拆分：将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务；

微服务需要考虑

微服务和SOA的区别

• Class Microservice implements SOA；

引言

• 本文介绍几种负载均衡架构及算法。

总体策略

• DNS负载均衡用于实现地理级别的负载均衡；
• 硬件负载均衡用于实现集群级别的负载均衡；
• 软件负载均衡用于实现机器级别的负载均衡；

硬件负载均衡

• 类似路由器、交换机；
• 优点：
  • 支持各种负载均衡算法；
  • 支持100万并发（一般软件负载均衡也就支持10万并发）；
  • 很多设备同时支持负载均衡、防火墙、防DDOS攻击功能；
• 缺点：
  • 价格高昂；

软件负载均衡

• 优点：
  • 便宜；
  • 维护和部署简单（安装Ngnix软件即可）；
• 缺点：
  • 并发量远小于硬件负载均衡，Linux服务器上装一个Nginx大概能到5万每秒；
  • 一般不具备防火墙、防DDOS攻击等功能；

DNS负载均衡

• 实现地理级别的负载均衡；
• DNS服务器将域名解析为最靠近用户的主机的IP地址，提升访问速度；
• 缺点：
  • DNS缓存不能及时更新，有可能定位到一个已经移走的主机；
  • 除了映射IP地址，没有提供其他的负载均衡算法和策略；

均衡算法

• 轮询：
  • 负载均衡系统收到请求后，按照顺序轮流分配到服务器上；
  • 算法简单，没有考虑机器的状态；
• 加权轮询：
  • 分给32核机器的概率是分给16核机器的概率的两倍；
  • 考虑了机器性能，但无法根据机器状态动态调整；
• 负载最低优先：
  • 根据及其具体状态决定负载均衡策略；
  • 考虑：机器连接数、机器的HTTP连接数、CPU占用率、IO占用率；
• 性能最佳优先：
  • 根据及其具体状态决定负载均衡策略；
  • 考虑：服务器响应时间；
• Hash：
  • 对源IP地址hash决定任务分配到哪台服务器；
  • 对session ID进行hash决定任务分配到哪台服务器，可以保证同一个会话的包都发送到同一台服务器处理；

引言

• 本文介绍几种基本架构及其优缺点

CAP原理

• 独裁者架构：
  • 优点：只有一个决策者，不会混乱；决策者随时掌控所有机器状态（上报者发送信条给决策者），实现统一调度；决策机器不存储数据，其他机器存储；
  • 缺点：一旦决策者宕机，集群群龙无首；

• 主备协商：
  • 优点：主机备机都存数据；从机平时不提供数据，只在主机出问题时升级为主机；主机坏了马上切换到备机；
  • 缺点：一旦主备机之间的通讯中断，则数据不同步。备机连不上主机，如果备机认为主机损坏，则自己升级为主机，如果主机实际上没有坏，外部用户会以为这个系统有两个主机，造成混乱。如果备机认为主机没有损坏，则自己不会升级为主机，如果主机实际上坏了，外部用户会以为这个系统没有主机，造成混乱。

• 主从协商：
  • 优点：从机正常情况下也是要提供读的操作；主从复制在主机故障时，读操作相关的业务可以继续运行；不浪费从机资源；
  • 缺点：可能数据不一致；

• 民主选举：
  • 介绍：只有一个管理者；多个独立个体自由交换信息；个体通过一定规则的选举生成管理节点；获得多数票者取胜；
  • 缺点：如果个体间部分通讯中断，则系统很有可能分裂为多个小集群，如果每个小集群都选举出一个管理者，则造成混乱，解决方法是规定投票节点数必须超过系统总节点数一半；

引言

• 本文介绍了CAP原理；

CAP原理

• 在一个分布式系统中，Consistency（数据一致性）、 Availability（服务可用性）、Partition tolerance（分区容错性），三者不可兼得；
• 一般来说，分布式系统优先实现P和A，C用最终一致性代替；

详细解释

• 一致性：All nodes see the same data at the same time；
• 可用性：A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout)；
• 分区容错性：出现消息丢失或者分区错误时系统能够继续运行；

使用案例

• 保证CP牺牲A：当系统不同节点间通讯中断、不能及时同步数据时，为了保证数据一致，此时对用户请求返回error错误信息，即系统暂时不可用；

• 保证AP牺牲C：有可能向用户返回旧数据，即脏读；

• 保证AC牺牲P：系统中只有一个节点，已经不是分布式系统；

引言

• 架构的设计在软件设计中极为重要，一个好的架构设计能够成倍提升开发和运维效率、提升产品的交付能力；
• 架构设计的思路和软件编程有很大不同，这不仅仅体现在所需知识的不同、而且思维模式和设计理念也各不相同；
• 在工作之余，我认真学习了极客时间的从0开始学架构课程，受益匪浅；
• 接下来我会用若干篇幅的博客展示一下学习笔记，欢迎大家指教；
• 本文对架构设计的原则和目的加以总结；

架构设计的目的

• 目的：解决软件系统复杂性带来的问题；
• 核心：balance；
  • 平衡希望系统高性能、高扩展性和时间成本、开发成本之间的矛盾；
  • 对各种设计的优缺点做取舍；

架构设计原则

• 合适优于业界领先：很适合别的系统的架构，不一定适合当前项目，不是每个系统都需要架构设计；
• 简单优于复杂：架构设计不是为了片面追求系统的高可用性、高扩展性、高性能，而是最适合业务的实际情况；
• 演化优于一步到位：架构是演化出来的，而不是设计出来的，谁都不可能在刚开始开发的时候、业务需求不明确的时候设计出完整的架构；

架构设计需要考虑

• 高性能：
  • 单机：充分利用CPU、disk、memory、IO等资源；
  • 集群：如何扩展单机的处理能力，满足业务需求，比如春节发红包、双十一等；
• 高可用：
  • 保证服务不间断正常运行；
  • 应对：硬件故障，软件故障、网络故障，外部故障（水灾地震）；
  • 保证高可用的核心：冗余；
• 可扩展性：
  • 正确预测变化、完美封装变化；
  • 所有的预测都存在出错的可能性；
  • 适度的预测而不是完美的预测；
• 安全性；

引言

• 量子论和相对论是现代物理学的两大支柱，共同构成了现代物理学的基本观点和理论；
• 在物理学的发展历程中，牛顿的经典物理学长期占据了不可撼动的主导地位，但人类对于宏观宇宙的探索不断表明，经典物理学仅适用于描述和解释低速、宏观物质的现象，并不能够解释物质在高速运动下表现出的规律和性质，所以才有了相对论；
• 相对论完美的阐释了时间、空间的本质，以及时空在目前宇宙尺度上的关系，并对处于人类观测极限的黑洞等天体的性质作出预测；
• 但随着科技的发展，人们逐步意识到相对论也不是完美的，在原子、质子以及电子的微观尺度上，发生了很多违背相对论原理的现象，这就说明在及其微观的尺度上，物质、时间、空间的性质和宏观尺度大不相同，描述和研究方法也应当有所转变，经过长时间的探索和不懈的追求，量子论横空出世，它以一种超乎寻常的全新的视角解释这个世界所发生的一切，让人类对于宇宙和自身的认知达到了新的高度；
• 量子论并不是理论的终点，也不是什么终极理论，量子论只是冰山一角，是解开这个宇宙所有谜团的入口，有更多的全新的事物等待人类继续不懈探索和追求；
• 本文结合自己对量子论的学习和认知，总结了量子论的基本观点，并对量子通信原理加以阐述，供您参考；
• 我不是物理学专业，如有错误敬请指出，为了方便理解，本文不含有任何公式；

量子的定义

• 量子是一切具有量子特性的微观粒子的统称，比如原子、质子、电子等等；
• 上述定义中的“量子特性”包括但不限于：波粒二象性、量子纠缠、不确定性等，这些性质本文中会一一阐述；
• 另一种定义方式：量子是能表现出某物质或物理量特性的最小单元；
• 实施上，上述定义中的“微观粒子”“最小单元”都是模糊的概念，由于量子学发展并未非常深入，所以这种定义本身就是模糊的，除非人类的认识达到了比量子还高的一个维度，才能在这个维度中对量子做出更加准确的定义；

相对论的时空观

• 在全面阐述量子论之前，首先对相对论的时空观加以概述，这样可以使读者抛弃宏观、低速的视角和思维模式，开启面向整个宇宙的思考，这样有利于更好的理解量子论；

宏观状态下的物质

• 牛顿的经典物理学对宏观低速状态的物质的性质做了非常经典的描述：
  • 第一定律：不受外力的物体将保持静止或匀速直线运动；
  • 第二定律：一个物体的外合力＝质量*加速度；
  • 第三定律：两个物体相互作用时，对彼此施加的力大小相等方向相反；
  • 万有引力定律：两个粒子间的作用力正比于它们质量的乘积，反比与它们中心点距离的平方；
  • 开普勒定律：在相等的时间内，太阳和围绕它运动的行星连线所扫过的面积相等；

相对论对光速的基本假设

• 光速(电磁波速)在任何情况、任何测量条件下保持恒定；
• 任何物质和信息速度不超过光速，在某种程度上，光速定义了整个宇宙；
• 光子没有静质量；

相对论对时间的描述

• 当物质的速度不断接近光速时，其性质不能够用经典物理学描述；
• 钟慢效应：当物质的速度不断接近光速时，物质的变化会相对于其静止时减慢，即物质的“时钟”变慢；
• 尺缩效应：当物质的速度不断接近光速时，测量的长度或距离，比地面上测得的短；
• 质量增加：快达到光速时，再向物体传递能量不能使速度明显增加，此时能量转化为质量；

相对论对空间的描述

• 万有引力的本质是大质量物质引起的空间形变，并不是力；
• 引力越大，天体内测光行进路线越短，由于光速不变，所以大质量天体内侧的时间流逝速度比外侧慢；
• 万有引力和加速度在对时空的影响上等效，一个飞行员如果承受了很大的加速度，他的时间会变慢；
• 对于人造卫星，由于相对地表速度快，所以时间流逝速度比地面慢，又由于高度位于地球外侧，所以时间流逝速度比地面快，后者的效应比前者大一个数量级，故人造卫星的时间快于地面，需要定期校准，否则卫星的时钟和地面的时钟不匹配，会造成GPS定位不准等一系列问题；

量子的物理属性

• 既然量子是物理学研究的范畴，那么必须要用相应的物理量来表征量子的性质；
• 量子的物理属性包括：质量、自旋、电荷，请注意，这里的“质量”这个物理属性和宏观物质的“质量”有本质不同，“自旋”是量子特有的属性，宏观物质不具备；
• 质量：
  • 对于微观粒子质量等价于能量，描述粒子裹携的能量的多少；
  • 对于微观粒子，质量和能量界限很模糊，对于宏观物质，质量和能量的界限很明确；
  • 组成质子的所有夸克质量相加只占质子质量的1%，质子的其他质量来源于夸克的动能，即夸克的巨大的但被束缚在一起的能量外在表现为质子的质量；
  • 这也说明物质的本质是能量，从宇宙的尺度上来讲，质量和能量本是一回事，质量是能量的特殊组织形式和外在表现；
  • 质量和能量一定条件下能相互转化，比如在物质高速运动时，对物体施加的动能可能转化为物体的质量；在核裂变反应中，物质的质量会转化为巨大的能量；
• 自旋：粒子在各个位置出现的概率分布图不断变化，变化一轮所需的周期；
• 电荷：描述粒子相互作用时产生各种电磁现象难易程度，分为正负，正电荷和负电荷对应的电磁现象正好相反；

量子的性质

• 本节介绍量子的基本性质；

不确定性原理

• 宏观物质一般是确定的、可测的；
• 微观粒子一般是不确定的、不可测的；
• 微观粒子的速度、动量、位置、质量等物理量不能同时具有确定数值；
• 一个值测的越准另一个值就越不准确；
• 单个粒子的这些属性往往以概率云的形式存在，仅仅在测量时(有光子干扰时，有信息交换时)概率云塌缩为确定的数值；

量子纠缠

• 微观粒子具有量子纠缠现象，即互为纠缠态的两个粒子无论空间距离多么遥远，也能瞬间影响对方的状态；
• 并不能利用这一现象使信息超光速传递，量子纠缠并不违反相对论基本原理；
• 量子纠缠的比喻：在美国的女儿生下孩子那一瞬间，远在中国的母亲就变成了姥姥，即便她自己还不知道，之所以她是姥姥别人不是，而且她一定会成为姥姥，就是因为她和女儿之间有一种“纠缠”关系；

波粒二象性

• 对波粒二象性的错误理解：单个粒子是”粒子”一大堆粒子就表现出”波”的性质；
• 波粒二象性是指，单个粒子本身即是波又是粒子；
• 这是因为单个粒子本身以概率云的形式存在，例如，一个电子既可以是波(一个电子不如果不对其测量，它可以同时穿过两条狭缝产生干涉条纹，但如果去测量它，产生了它与外界的信息交换，它会确切的随机的穿过某一条狭缝而不产生干涉条纹)，又可以是粒子(可以与光子碰撞)；

如何理解薛定谔的猫

• 薛定谔的猫是著名的思想实验；
• 将一只猫关在一钢盒内，盒中有极残忍的装置（必须保证此装置不受猫的直接干扰），在盖革计数器中有一小块辐射物质，它非常小，或许在1小时中只有一个原子衰变，在相同的几率下或许没有一个原子衰变；
• 如果发生衰变，计数管便放电并通过继电器释放一个锤，击碎一个小小的氰化物瓶毒杀了这只猫，否则不会；
• 常识告诉我们那只猫非死即活，两者必居其一，可是按照量子力学的规则，盒内整个系统处于两种态的叠加之中，一态中有活猫，另一态中有死猫，即量子理论告诉我们，这个不幸的动物处于一种悬而未决的死活叠加状态中；
• 这个实验巧妙地将微观世界的不确定性原理和宏观世界的确定、可测联系起来，让人摸不着头脑，事实上，宏观世界的确定和微观世界的不确定两者并不矛盾，只是人们尚未发现为何及其大量的微观不可测事件导致了宏观的确定性，我们到底是生活在确定还是不确定中目前还没有定论；

量子的分类

费米子

• 具有半整数自旋，每一种都有反粒子相对应；
• 夸克：
  • 下夸克：自旋1/2，电荷－1/3；
  • 上夸克：自旋1/2，电荷＋2/3；
  • 奇夸克：自旋0，电荷－1/3；
  • 粲夸克：自旋0，电荷＋2/3；
  • 底夸克：自旋0，电荷－1/3；
  • 顶夸克：自旋0，电荷＋2/3；
• 轻子：
  • 电子/正电子：电荷±1；
  • μ子/反μ子：电荷±1；
  • τ子/反τ子：电荷±1；
  • (反)电子中微子：电荷0；
  • (反)μ子中微子：电荷0；
  • (反)τ子中微子：电荷0；

玻色子

• 具有整数自旋；
• 光子：自旋1，电荷0，静质量0(指的是没有静止不动的光子)，能量来自电磁相互作用；
• W玻色子：自旋1，电荷1，能量来自弱相互作用；
• Z玻色子：自旋1，电荷0，能量来自弱相互作用；
• 胶子：自旋1，电荷0，能量来自强相互作用；
• 引力子：自旋2，电荷0，能量来自引力相互作用；
• 希格斯玻色子：自旋0，电荷0，能量来自电弱交互作用；

量子通信基本原理

• 量子通信本质上是利用量子的“纠缠”特性；
• 利用量子论实现光量子通信的过程如下：
  • 首先先构建一对相互纠缠的粒子，将这两个粒子分别放在发送方和接收方；
  • 将具有未知量子态的粒子与发送方的粒子进行联合测量(一种操作)，这种操作改变了发送方粒子的量子态；
  • 根据量子的自旋特性，接收方的粒子会在瞬间(不耗费任何时间)发生坍塌(一种量子性质的改变) ，坍塌后的状态与发送方的粒子坍塌后的状态是对称的；
  • 然后将联合测量的信息通过经典信道传送给接收方，接收方根据接收到的信息对坍塌的粒子进行幺正变换(相当于逆转变换)，即可得到与发送方完全相同的未知量子态;
• 经典通信较光量子通信相比，其安全性和高效性都无法与之相提并论：
  • 安全性：量子通信绝不会“泄密”，其一体现在量子加密的密钥是随机的，即使被窃取者截获，也无法得到正确的密钥，因此无法破解信息；其二，分别在通信双方手中具有纠缠态的2个粒子，其中一个粒子的量子态发生变化，另外一方的量子态就会随之立刻变化，并且根据量子理论，宏观的任何观察和干扰，都会立刻改变量子态，引起其坍塌，因此窃取者由于干扰而得到的信息已经破坏，并非原有信息；
  • 高效，被传输的未知量子态在被测量之前会处于纠缠态，即同时代表多个状态，例如一个量子态可以同时表示0和1两个数字，7个这样的量子态就可以同时表示128个状态或128个数字0~127，光量子通信的这样一次传输，就相当于经典通信方式的128次；

引言

• ELK是重要的日志分析系统，在开源的日志分析系统中独占鳌头，最近公司业务用ELK分析告警日志，故系统研究了Elasticsearch的工作原理。
• 本文是转载的一篇文章加上我自己的整理和分析，某些内容和ELK官网重复，在此感谢作者的整理。

基本概念

• 简介：
  • ElasticSearch(以下简称ES)是一个基于Lucene构建的开源(open-source)，分布式(distributed)，RESTful，实时(real-time)的搜索与分析(analytics)引擎。
  • 它可以让你在浏览数据时具备非常快的速度和优秀的可扩展性。它用于全文索引、结构化数据索引、数据分析以及三者的结合。
  • 它可以运行在你的笔记本上，或者扩展至数百台的服务器节点上来处理PB级的数据。 ES建立在Lucene的基础之上，但是Lucene仅仅是一个库，如果要发挥它的优势，你必须使用它然后再结合自己的开发来构造一个具体的应用。
  • 更坏的是你必须了解Lucene才能更好的使用它，但是Lucene本身就很复杂。所以ES意在取Lucene的优点，隐蔽其复杂性来构造一个简洁易用的RESTful风格的全文搜索引擎。
• 与关系型数据库的名词对照

SQL database	No-sql database
database	database
table	collection
row	document
column	field
primary key	primary key

• ElasticSearch专用名词解释：

  • document：一行数据；
  • index：一个database，是多个document的集合（和sql数据库的索引的概念不同），在kibana上显示为一组日志；
  • shard：ELK的底层存储是file，shared包含一个或多个file，是数据最小存储单元，一个index被划分为若干shared分片，一个shared可以备份到其他节点上（备份的份数可以自定义）；
  • node：物理节点；
  • cluster：集群；

• 面向文档(Document Oriented)

  • 在应用程序中的对象(Objects)，不仅仅是keys和values的罗列，更多的是，他们是由更为复杂的数据结构组成的数据构成的。迟早你会将这些对象存储到DataBases(这里指更广义的持久层)。如果你要将这些已经通过复杂的结构体组织好的对象存储到传统的ROWS-COLUMNS的关系型数据库里无疑等于压榨你的财富：因为你必须将这些已经组织好了的复杂结构扁平化来适应传统数据库的表结构(通常是一个列一个字段)，然后以后每次在你要使用这个数据的时候再重组它们。
  • ES面向文档，这就意味着你可以存储完整的对象或者文档。ES不仅存储它们，并且对它们的每一个文档的内容做了索引以便可以查询到它们。在ES中，你是对文档进行的建索引、查询、排序、过滤，而不是对关系型数据的一行数据。这就是ES处理数据的一个最基本的不同点，这也是ES为什么能处理全文索引的关键。

• 精确索引VS全文索引

  • 在ES中的数据可以分为两类：精确值(exact values)以及全文(full text)。 精确值：例如日期类型date，若date其有两个值:2014-09-15与2014，那么这两个值不相等。又例如字符串类型foo与Foo不相等。 全文：通常是人类语言写的文本，例如一段tweet信息、email的内容等。
  • 精确值很容易被索引：一个值要么相当要么不等。 索引全文值就需要很多功夫。例如我们不仅要想：这个文档符合我们的查询吗？还要想：这个文档有多符合我们的查询？换句话说就是：这个文档跟我们的查询关联大吗？我们很少精确的去匹配整个全文，我们最想要的是去匹配全文文本的内部信息。除此，我们还希望搜索能够理解我们的意图;
  • 例如,如果你搜索UK，我们需要包含United Kingdom的文本也会被匹配。如果你搜索jump，那么包含jumped,jumps,jumping,更甚者leap的文本会被匹配。
  • 为了更方便的进行全文索引，ES首先要先分析文本，然后使用分析过的文本去创建倒序索引。

• 倒序索引&文本分析

  • ES使用倒序索引来加速全文索引。一个倒序索引由两部分组成：在文档中出现的所有不同的词；对每个词，它所出现的文档的列表。 例如：如果我们有两个文档，每一个文档有一个content字段，包含的内容如下：

1.The quick brown fox jumped over the lazy dog
2.Quick brown foxes leap over lazy dogs in summer

要创建一个倒序索引，首先要将content分割成单独的词(称为terms or tokens)，创建一个所有terms的列表，然后罗列每一个term出现的文档。此过程称为tokenization。如下图：

现在，如果我们想要搜索 quick brown，我们仅仅只需要找每一个term出现的文档即可。如下图：

每一个文档都匹配到了，但是第一个比第二个要匹配的多。如果我们使用一个简单的相似性算法仅仅只计算匹配的数量，那么我们可以称第一个文档要比第二个匹配的好(与我们的查询更有关联)。
但是现在的倒序索引有一些问题：

Quick与quick是两个不同的term，但是搜索的用户会认为它们应该是一样的term才是合理的。
fox和foxes，dog和dogs是一样的词根，应该列为同一个term。 jumped和leap虽然词根不一样，但是意义却相同。

如果改善了上面的问题，那么倒序索引应该如下图：

但是此时如果用户搜索Quick还会失败，因为term不含精确值Quick。但是，如果我们对QueryString使用与上述改善步骤相同的策略，那么用户搜索的Quick将会被转换为quick，此过程称为normalization。那么将会成功匹配。 对content的处理tokenization和normalization称为analysis过程。ES有很多种内置的analyzer处理这些。

Elasticsearch设计原理

一个空的集群

• 如果我们启动了一个节点，没有索引没有数据，那么看起来就像上图一样。 一个节点Node运行着ES的实例，一个集群由一个或多个使用着同样名字(cluster.name)的节点组成，分享数据和负载。 当Node从集群中添加或删除时，集群会重组自己，使数据平摊的更均匀。
• 集群中需要有一台master节点。master的作用是掌管集群的管理工作： 例如创建和删除索引。 从集群中添加或删除一台节点。 master节点无需掌管文档级的变更和索引。这也意味着在只有一台master的情况下，随着负载的增加master不会成为瓶颈。 所有的节点都可能变成master。
• 作为user，我们可以与任何一台节点通信，包括master。每一台节点都知道每一个文档的位置并且可以将user的请求路由到文档所在的节点，并且这台节点负责接收它路由到的node or nodes的响应，并且将数据组织起来返回给用户。这些对用户都是透明的。

创建一个索引—index,shard,cluster

• 将数据添加到ES的前提是，我们需要一个索引(名词):index——一个存储与这个索引相对应数据的地方。实际上，index仅仅只是一个命名空间来指向一个或多个实际的物理分片(shard)。
• 一个分片(shard)是一个比较低层的工作单元来处理这个索引(index)的所有数据的一个切片(slice)。一个shard实际上是一个Lucene实例，在它的能力范围内拥有完整的搜索功能(在处理它自己拥有的数据时有所有的功能)。我们所有文档的索引indexed(动词)和存储工作都是在shard上，但这是透明的，我们不需要直接和shard通信，而是和我们创建的index(名词)通信。
• shards是ES将数据分布式在你的集群的关键。想象下shards是数据的容器，文档存储在shards里，而shards被分配在集群的每一个节点Node里。当你的集群规模增长和降低时，ES会自动的在Nodes间迁移shards以保持集群的负载均衡。
• shard的分类与作用：
  • shard可分为primary shard和replica shard。
  • 在一个index里的每一个文档都属于一个单独的primary shard，所以primary shard的数量决定了你最大能存储的数据量(对应于一个index)。
  • 注意：shard是归属与index的，而不是cluster的。
• replica shard是primary shard的拷贝。replica有两个作用：
  • 冗余容灾
  • 提供读请求服务，例如搜索或读取文档primary shard的数量在索引创建时确定后不能修改，replica可以在任何时候修改。 例： 见Figure2，在2.1的集群上创建一个index，拥有3个primary shards以及1个replica shards。

由于只有一台Node，而Primary shard的Replicas与其在同一台节点上毫无意义，所以集群没有初始化replicas，这时添加另外一台Node。见Figure3，每一个primary shard初始化了一个replica。

水平扩容

当我们继续添加一台节点时，Node1和Node2中的各取一个shard移动到了Node3.见Figure4

这样，我们每一台Node上只有两个shard。这就意味着每一台Node的硬件资源(CPU,RAM,I/O)将会被更少的shards共享，提高了每一个shard的性能。在这个案例中，6个shards最多可使用6台Node，这样每个shard就可以使用100%的node硬件资源。
现在我们修改replica的数量到2，如Figure5

这样我们就有了一个3primary shards，6replica shards的Cluster。我们可将Node提高到9台。水平扩容了集群性能。

容灾

ES可以容下当节点宕机情况下的异常。例如现在我们杀掉Node1节点。见Figure6

我们杀掉的是master节点。一个Cluster必须要有master以保证集群的功能正常。所以集群要做的第一件事是选择一个新的master：Node2. 当我们杀掉1节点时，Primary shards 1和2丢失了。如果丢失了primary shard，index(名词)将不能正常的工作。此时P1和P2的拷贝存在Node2和Node3上。所以此时新升级的master(Node2)将做的第一件事就是将NODE2和NODE3上的replica shard1和replica shard2升级为primary shard。此时如果我们杀掉NODE2，整个集群的容灾过程同理，还是可以正常运行。

这时，如果我们重启了NODE1，cluster将会重新分配缺少的两个replica shards(现在每个primary shard只有2个replicas，配置是3个，缺少2个)。如果NODE1的数据是旧的，那么它将会继续利用它们，NODE1只会从现在的Primary Shards拷贝这期间更改的数据。

分布式文档存储

Shards文档路由

当你对一个文档建立索引时，它仅存储在一个primary shard上。ES是怎么知道一个文档应该属于哪个shard？当你创建一个新的文档时，ES是怎么知道应该把它存储至shard1还是shard2？ 这个过程不能随机无规律的，因为以后我们还要将它取出来。它的路由算法是：

shard = hash(routing) % numberofprimary_shards

routing的值可以是文档的id，也可以是用户自己设置的一个值。hash将会根据routing算出一个数值然后%primaryshards的数量。这也是为什么primary_shards在index创建时就不能修改的原因。

问题：当看到这里时，产生了一个问题:ES为什么要这样设计路由算法，这样就强制使primaryshards不可变，不利于以后index的扩容，除非事前就要对数据规模有所评估来设计可扩展的index。为什么不能使用一致性hash解决primaryshards改变时的情况呢？

Primary/Replica Shards的交互

假如我们有Figure8的集群。我们可以向这个集群的任何一台NODE发送请求，每一个NODE都有能力处理请求。每一个NODE都知道每一个文档所在的位置所以可以直接将请求路由过去。下面的例子，我们将所有的请求都发送到NODE1。

注：最好的实践方式是轮询所有的NODE来发送请求，以达到请求负载均衡。

写操作

创建、索引、删除文档都是写操作，这些操作必须在primary shard完全成功后才能拷贝至其对应的replicas上。见Figure9。

1.客户端向Node1发送写操作的请求。
2.Node1使用文档的_id来决定这个文档属于shard0，然后将请求路由至NODE3，P0所在的位置。
3.Node3在P0上执行了请求。如果请求成功，则将请求并行的路由至NODE1 NODE2的R0上。当所有的replicas报告成功后，NODE3向请求的node(NODE1)发送成功报告，NODE1再报告至Client。
当客户端收到执行成功后，操作已经在Primary shard和所有的replica shards上执行成功了。

读操作

一个文档可以在primary shard和所有的replica shard上读取。见Figure10

1.客户端发送Get请求到NODE1。
2.NODE1使用文档的_id决定文档属于shard 0.shard 0的所有拷贝存在于所有3个节点上。这次，它将请求路由至NODE2。
3.NODE2将文档返回给NODE1，NODE1将文档返回给客户端。 对于读请求，请求节点(NODE1)将在每次请求到来时都选择一个不同的replica。
shard来达到负载均衡。使用轮询策略轮询所有的replica shards。

更新操作

更新操作，结合了以上的两个操作：读、写。见Figure11

1.客户端发送更新操作请求至NODE1
2.NODE1将请求路由至NODE3，Primary shard所在的位置
3.NODE3从P0读取文档，改变source字段的JSON内容，然后试图重新对修改后的数据在P0做索引。如果此时这个文档已经被其他的进程修改了，那么它将重新执行3步骤，这个过程如果超过了retryon_conflict设置的次数，就放弃。
4.如果NODE3成功更新了文档，它将并行的将新版本的文档同步到NODE1和NODE2的replica shards重新建立索引。一旦所有的replica
shards报告成功，NODE3向被请求的节点(NODE1)返回成功，然后NODE1向客户端返回成功。

Shard以及数据读写方式的设计

不变性

• 写到磁盘的倒序索引是不变的：自从写到磁盘就再也不变。这会有很多好处：
  • 不需要添加锁。如果你从来不用更新索引，那么你就不用担心多个进程在同一时间改变索引。
  • 一旦索引被内核的文件系统做了Cache，它就会待在那因为它不会改变。只要内核有足够的缓冲空间，绝大多数的读操作会直接从内存而不需要经过磁盘。这大大提升了性能。
  • 其他的缓存(例如fiter cache)在索引的生命周期内保持有效，它们不需要每次数据修改时重构，因为数据不变。
  • 写一个单一的大的倒序索引可以让数据压缩，减少了磁盘I/O的消耗以及缓存索引所需的RAM。
• 当然，索引的不变性也有缺点。如果你想让新修改过的文档可以被搜索到，你必须重新构建整个索引。这在一个index可以容纳的数据量和一个索引可以更新的频率上都是一个限制。

动态更新索引

如何在不丢失不变形的好处下让倒序索引可以更改？答案是：使用不只一个的索引。 新添额外的索引来反映新的更改来替代重写所有倒序索引的方案。 Lucene引进了per-segment搜索的概念。一个segment是一个完整的倒序索引的子集，所以现在index在Lucene中的含义就是一个segments的集合，每个segment都包含一些提交点(commit point)。见Figure16。新的文档建立时首先在内存建立索引buffer，见Figure17。然后再被写入到磁盘的segment，见Figure18。

• 一个per-segment的工作流程如下：
  • 新的文档在内存中组织，见Figure17。
  • 每隔一段时间，buffer将会被提交：一个新的segment(一个额外的新的倒序索引)将被写到磁盘 一个新的提交点(commit point)被写入磁盘，将包含新的segment的名称。 磁盘fsync，所有在内核文件系统中的数据等待被写入到磁盘，来保障它们被物理写入。
  • 新的segment被打开，使它包含的文档可以被索引。
  • 内存中的buffer将被清理，准备接收新的文档。
• 当一个新的请求来时，会遍历所有的segments。词条分析程序会聚合所有的segments来保障每个文档和词条相关性的准确。通过这种方式，新的文档轻量的可以被添加到对应的索引中。

删除和更新

• segments是不变的，所以文档不能从旧的segments中删除，也不能在旧的segments中更新来映射一个新的文档版本。取之的是，每一个提交点都会包含一个.del文件，列举了哪一个segmen的哪一个文档已经被删除了。 当一个文档被”删除”了，它仅仅是在.del文件里被标记了一下。被”删除”的文档依旧可以被索引到，但是它将会在最终结果返回时被移除掉。
• 文档的更新同理：当文档更新时，旧版本的文档将会被标记为删除，新版本的文档在新的segment中建立索引。也许新旧版本的文档都会本检索到，但是旧版本的文档会在最终结果返回时被移除。

实时索引

• 在上述的per-segment搜索的机制下，新的文档会在分钟级内被索引，但是还不够快。 瓶颈在磁盘。将新的segment提交到磁盘需要fsync来保障物理写入。但是fsync是很耗时的。它不能在每次文档更新时就被调用，否则性能会很低。
• 现在需要一种轻便的方式能使新的文档可以被索引，这就意味着不能使用fsync来保障。 在ES和物理磁盘之间是内核的文件系统缓存。之前的描述中,Figure19,Figure20，在内存中索引的文档会被写入到一个新的segment。但是现在我们将segment首先写入到内核的文件系统缓存，这个过程很轻量，然后再flush到磁盘，这个过程很耗时。但是一旦一个segment文件在内核的缓存中，它可以被打开被读取。

更新持久化

不使用fsync将数据flush到磁盘，我们不能保障在断电后或者进程死掉后数据不丢失。ES是可靠的，它可以保障数据被持久化到磁盘。 在2.6.2中，一个完全的提交会将segments写入到磁盘，并且写一个提交点，列出所有已知的segments。当ES启动或者重新打开一个index时，它会利用这个提交点来决定哪些segments属于当前的shard。 如果在提交点时，文档被修改会怎么样？不希望丢失这些修改：

• 当一个文档被索引时，它会被添加到in-memory buffer，并且添加到Translog日志中，见Figure21.

• refresh操作会让shard处于Figure22的状态：每秒中，shard都会被refreshed，在in-memory buffer中的文档会被写入到一个新的segment，但没有fsync，in-memory buffer被清空。

• 这个过程将会持续进行：新的文档将被添加到in-memory buffer和translog日志中，见Figure23

• 一段时间后，当translog变得非常大时，索引将会被flush，新的translog将会建立，一个完全的提交进行完毕。见Figure24
  • 在in-memory中的所有文档将被写入到新的segment.
  • 内核文件系统会被fsync到磁盘。
  • 旧的translog日志被删除

translog日志提供了一个所有还未被flush到磁盘的操作的持久化记录。当ES启动的时候，它会使用最新的commit point从磁盘恢复所有已有的segments，然后将重现所有在translog里面的操作来添加更新，这些更新发生在最新的一次commit的记录之后还未被fsync。

translog日志也可以用来提供实时的CRUD。当你试图通过文档ID来读取、更新、删除一个文档时，它会首先检查translog日志看看有没有最新的更新，然后再从响应的segment中获得文档。这意味着它每次都会对最新版本的文档做操作，并且是实时的。

Segment合并

• 通过每隔一秒的自动刷新机制会创建一个新的segment，用不了多久就会有很多的segment。segment会消耗系统的文件句柄，内存，CPU时钟。最重要的是，每一次请求都会依次检查所有的segment。segment越多，检索就会越慢。
• ES通过在后台merge这些segment的方式解决这个问题。小的segment merge到大的，大的merge到更大的。。。
• 这个过程也是那些被”删除”的文档真正被清除出文件系统的过程，因为被标记为删除的文档不会被拷贝到大的segment中。合并过程如Figure25：
  • 当在建立索引过程中，refresh进程会创建新的segments然后打开他们以供索引。
  • merge进程会选择一些小的segments然后merge到一个大的segment中。这个过程不会打断检索和创建索引。
  • Figure26，一旦merge完成，旧的segments将被删除：新的segment被flush到磁盘，一个新的提交点被写入，包括新的segment，排除旧的小的segments，新的segment打开以供索引旧的segments被删除。

merge大的segments会消耗大量的I/O和CPU，严重影响索引性能。默认，ES会节制merge过程来给留下足够多的系统资源。