容错机制

本文是我在学习微服务时看的其他博主介绍的一篇概念文章，觉得写得非常清晰全面、非常好，所以转载过来分享给大家一起学习。 原文地址：https://blog.csdn.net/Soinice/article/details/83989225 前言 到底什么是微服务？为什么要用微服务？微服务主要来做一些什么？微服务有哪些优势？什么样的服务属于微服务？本文所有资料来源网络，我只是整理一下，总结一下。仅供参考。 一、微服务介绍 1.什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"。 微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务是一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 2. 微服务由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署

状态如何保存和恢复 1.定时制作分布式快照，对程序中的状态进行备份 2.发生故障时： 将整个作业中所有的task都回滚到最后一次成功的checkpoint中的状态，然后从那个点开始执行； 3.必要条件：数据支持重发的 4.一致性语句：恰好一次， 至少一次 checkpoint执行机制 1.checkpoint coordinate向所有的source发送trigger checkpoint 2.所有的task接收到barrier后，会执行快照，并将自己的输出传递到新的barrier，将自己的状态持久化。 3.当task完成备份之后，会将数据地址通知checkpoint coordinate。 来源： https://www.cnblogs.com/yankang/p/11576103.html

1、图解Elasticsearch容错机制：master选举，replica容错，数据恢复 （1）9 shard，3 node （2）master node宕机，自动master选举，red （3）replica容错：新master将replica提升为primary shard，yellow （4）重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green 来源： https://www.cnblogs.com/siye1989/p/11559421.html

checkpoint是Flink容错的核心机制。它可以定期地将各个Operator处理的数据进行快照存储（ Snapshot ）。如果Flink程序出现宕机，可以重新从这些快照中恢复数据。 1. checkpoint coordinator（协调器）线程周期生成 barrier （栅栏），发送给每一个source 2. source将当前的状态进行snapshot（可以保存到HDFS） 3. source向coordinator确认snapshot已经完成 4. source继续向下游transformation operator发送 barrier 5. transformation operator重复source的操作，直到sink operator向协调器确认snapshot完成 6. coordinator确认完成本周期的snapshot 代码设置示例： // 5 秒启动一次 checkpoint env.enableCheckpointing(5000) // 设置 checkpoint 只 checkpoint 一次 env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE) // 设置两次 checkpoint 的最小时间间隔 env.getCheckpointConfig

一、微服务介绍 1. 什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 2. 微服务由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 3. 为什么需要微服务？ 在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高

本文是博主阅读Flink官方文档以及《Flink基础教程》后结合自己理解所写，若有表达有误的地方欢迎大伙留言指出。 1. 前言 　　 　　流式计算分为有状态和无状态两种情况，所谓状态就是计算过程中的中间值。对于无状态计算，会独立观察每个独立事件，并根据最后一个事件输出结果。什么意思？大白话举例：对于一个流式系统，接受到一系列的数字，当数字大于N则输出，这时候在此之前的数字的值、和等情况，压根不关心，只和最后这个大于N的数字相关，这就是无状态计算。什么是有状态计算了？想求过去一分钟内所有数字的和或者平均数等，这种需要保存中间结果的情况是有状态的计算。 　　当分布式计系统中引入状态计算时，就无可避免一致性的问题。为什么了？因为若是计算过程中出现故障，中间数据咋办了？若是不保存，那就只能重新从头计算了，不然怎么保证计算结果的正确性。这就是要求系统具有容错性了。 2. 一致性 　　谈到容错性，就没法避免一致性这个概念。所谓一致性就是：成功处理故障并恢复之后得到的结果与没有发生任何故障是得到的结果相比，前者的正确性。换句大白话，就是故障的发生是否影响得到的结果。在流处理过程，一致性分为3个级别[1]： 　　at-most-once：故障发生之后，计算结果可能丢失，就是无法保证结果的正确性； 　　at-least-once：计算结果可能大于正确值，但绝不会小于正确值

比特币的学术谱系，Part-1 如果你读过比特币的新闻报道，并且熟悉密码学领域的学术研究的话，你应当会留下这样的印象：自 David Chaum 10,12 起，学术界对数字货币展开了长达数十年的研究，却未能取得商业上的成功，因为整个数字货币系统需要一个类似银行的中心化服务机构加以控制，事实上没有一家银行对此感兴趣。比特币则另辟蹊径，提出了创建无需银行的去中心化加密货币的想法，数字货币终于迎来了成功。人们普遍认为，神秘的比特币之父中本聪并非学术界人士，比特币与之前的学术设想毫无相似之处。 为反对上述观点，本文特别列出了图 1，显示比特币用到的所有技术几乎都源自 20 世纪 80 和 90 年代。笔者并非有意贬低中本聪的贡献，而是要指出他也是站在巨人的肩膀上。通过对比特币概念的溯源，我们可以专注于中本聪在洞察力上的真正飞跃——他是如何通过某种准确且复杂的方式将这些技术结合起来的。这有助于解释为什么比特币这么晚才诞生。已经熟悉了比特币运作原理的读者或许能从这些历史回顾中获得更深刻的理解。（请参见 Arvind Narayanan 等人所著的《比特币和加密货币技术》作为入门读物36。）比特币的学术史也作为一项案例研究，展示了学术界人士、外部研究人员和相关从业人士之间的关系，并分享了三方如何互相受益的经验之谈。 账本 如果你有一个安全的账本，将它应用于数字支付系统的过程很简单。举例来说