分布式技术

在分布式系统中，同时满足“一致性”、“可用性”和“分区容错性”三者是不可能的。分布式系统的事务一致性是一个技术难题，各种解决方案孰优孰劣？老司机介绍 丁浪，现就职于某垂直电商平台，担任技术架构师。关注高并发、高可用的架构设计，对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 在OLTP系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，例如最经典的Bob给Smith转账的案例。传统的企业开发，系统往往是以单体应用形式存在的，也没有横跨多个数据库。 我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比较杂，尤其是在SOA和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和解决方案，已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者，可能听说过“CAP定律”、“Base理论”等，非常巧的是

为什么在分布式Java应用程序中使用缓存？今天学习了两节优锐课讲解分布式缓存的内容，收获颇多，分享给大家。 在提高应用程序的速度和性能时，每毫秒都是至关重要的。例如，根据Google的一项研究，如果网站在3秒或更短时间内无法加载，则有53％的移动用户会离开该网站。 缓存是使你的分布式应用程序更快的最重要的技术之一。你可以将信息存储到计算机的CPU中越近，访问信息的速度就越快。从CPU缓存中加载数据要比从RAM中加载数据快得多，这也比从硬盘或通过网络加载数据快得多。 为了存储经常访问的数据，分布式应用程序在多台计算机上维护高速缓存。分布式缓存通常是减少分布式应用程序的延迟并提高其并发性和可伸缩性的基本策略。 Redis是一种流行的开源内存中数据结构存储，可以用作数据库，缓存或消息代理。因为Redis从内存而不是从磁盘加载数据，所以Redis比许多传统的数据库解决方案要快。 但是，使分布式缓存在Redis中正常工作对于开发人员可能是一个挑战。例如，本地缓存失效是替换或删除缓存条目的过程，必须谨慎处理。每次更新或删除一台计算机上本地缓存中存储的信息时，都必须更新作为分布式缓存一部分的所有计算机上的内存中缓存。 好消息是，有Redis框架（例如Redisson）可以帮助你构建应用程序所需的分布式缓存。在下一部分中，我们将讨论Redisson中三种重要的分布式缓存实现：Maps，Spring

在分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（replica）, 这些副本会放置在不同的节点上。这些数据节点可能是物理机器，也可能是虚拟机。为了对用户提供正确的CURD等语意，我们需要保证这些放置在不同节点上的副本是一致的，这就涉及分布式事务的问题。 本文介绍分布式事务处理方案之一的两阶段提交协议。 分布式事务 分布式事务是指发生在多个数据节点之间的事务，分布式事务比单机事务要复杂的多。在分布式系统中，各个节点之间在是相互独立的，需要通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确地知道其他节点的事务执行情况。所以从理论上来讲，两个节点的数据是无法达到一致的状态。如果想让分布式部署的多个节点中的数据保持一致性，那么就要保证在所有节点数据的写操作，要么全部都执行，要么全部都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果，所以它也就不知道本次事务到底应该commit还是rollback。所以，常规的解决办法就是引入一个"协调者"的组件来统一调度所有分布式节点的执行。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Commitment Protocol）

背景 开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。 RocketMQ消息产生后，生产者希望在间隔一段时间后被消费的场景可以使用定时消息，RocketMQ目前不支持自定义延迟时间，但可以指定延迟等级，可以选择18个延迟等级，分别是对应延迟时间是1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。 RocketMQ的延迟消息主题是SCHEDULE_TOPIC_XXXX，18个延迟级别对应18个消息队列，当消息投递到broker后，如果消息中指定了延迟等级（DelayTimeLevel），消息topic会更改为SCHEDULE_TOPIC_XXXX，queueId更改为延迟等级对应的消息队列，原有的topic和queueId会放到msg属性的REAL_TOPIC与REAL_QID中。 本地延时

漫谈分布式系统 1.分布式架构中的相关概念 2.分布式架构的发展过程和历史 3.分布式架构的难点 ==================================== 一. 分布式架构中的相关概念 1.集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群 2.分布式 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群 3.节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中，一个节点表示的是一个操作系统上的进程。 4.副本 副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。节点的数据丢失时，可以从副本上读取到数据。数据副本是分布式系统中解决数据丢失问题的唯一手段。服务副本表示多个节点提供相同的服务，通过主从关系来实现服务的高可用方案 5.中间件 中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分。 二. 分布式架构的发展过程和历史 一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性

提起大数据，不得不提由IBM提出的关于大数据的5V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性），而对于大数据领域的从业人员的日常工作也与这5V密切相关。大数据技术在过去的几十年中取得非常迅速的发展，尤以Hadoop和Spark最为突出，已构建起庞大的技术生态体系圈。 首先通过一张图来了解一下目前大数据领域常用的一些技术，当然大数据发展至今所涉及技术远不止这些。 BigData Stack： 下面分不同层介绍各个技术，当然各个层并不是字面意义上的严格划分，如Hive既提供数据处理功能也提供数据存储功能，但此处将其划为数据分析层中 1. 数据采集和传输层 Flume Flume一个分布式、可靠的、高可用的用于数据采集、聚合和传输的系统。常用于日志采集系统中，支持定制各类数据发送方用于收集数据、通过自定义拦截器对数据进行简单的预处理并传输到各种数据接收方如HDFS、HBase、Kafka中。之前由Cloudera开发，后纳入Apache Logstash ELK工作栈的一员，也常用于数据采集，是开源的服务器端数据处理管道 Sqoop Sqoop主要通过一组命令进行数据导入导出的工具，底层引擎依赖于MapReduce，主要用于Hadoop（如HDFS、Hive、HBase）和RDBMS（如mysql

这书以分布式微服务系统为主线，讲解了微服务架构设计、分布式一致性、性能优化等内容，并介绍了与微服务系统紧密联系的日志系统、全局调用链、容器化等。 还是一样，每一章摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。 第1章 分布式微服务架构设计原理 1. 由传统单体架构到服务化架构 （老生常谈，感觉所有谈到微服务的内容都是从这个角度开始叙述。） （1）J2EE是二八原则的典型应用场景：它将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现20%的专用逻辑，并 通过配置的形式来访问应用服务器提供的模块化组件 。 （2）康威定律 设计系统的组织时，最终产生的设计等价于组织的沟通结构，通俗来说， 团队的交流机制应该与架构设计机制相对应 。 （3）Java AOP的实现方式有三种 1》对Java字节码进行 重新编译 ，将切面插入字节码的某些点和面上，可以使用 cglib库 实现 2》定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻辑外的功能，JVM自身提供的 Java Agent机制 就是在 加载类的字节码时 ，通过增加切面来实现AOP的。 3》JVM本身提供了 动态代理组件 ，可以通过它实现任意对象的代理模式， 在代理的过程中 可以插入切面的逻辑。可以使用Java提供的APIProxy

=======开篇吐槽：最近一段时间刚好碰上中秋国庆双节，而且工作任务繁重，基本很难保证有时间来写文章了======= 《可伸缩服务架构 框架与中间件》与《分布式服务架构 原理、设计与实战》是要配套捆绑着看，这营销手段，服。 这书主要介绍了在分布式系统中常规用到的一些框架组件，比如分布式ID、消息队列、缓存、RPC框架、ES等。书中大部分内容的作用更多的是整体介绍、知识点扩展、初步入门，书中贴的源代码其中很难让人认真一行一行去阅读学习。想要更深入的学习，需要在平时工作多积累丰富的项目经验，或者多看看开源项目，从而去总结和提取。 每一章介绍一个组件，摘抄一些自己觉得有用的内容，归纳整理，然后加以理解。（主要还是强迫自己形成总结成文的习惯，看的书很多，都总是很容易忘记，效果甚微） 第1章 如何设计一款永不重复的高性能分布式发号器 1. 为什么不直接采用UUID？ 虽然UUID能够保证唯一性，但无法满足业务系统需要的很多其他特性，比如时间粗略有序性、可反解和可制造性（说人话，就是分布式ID需要体现根据时间递增的特点，并且从ID串中能解析出一定的业务含义），同时UUID比较长，占空间大，性能较差。 2. 那基于数据库来实现呢？ 即通过调整自增字段或者数据库sequence的步长来确保跨数据库的ID的唯一性，但这种方案强依赖于数据库。 实现方案，可见我：重构 - 分布式ID设计方案 3.

1.1Hazelcast概述 Hazelcast是基于内存的数据网格开源项目，同时也是该公司的名称。Hazelcast提供弹性可扩展的分布式内存计算，Hazelcast被公认是提高应用程序性能和扩展性最好的方案。Hazelcast通过开放源码的方式提供以上服务。更重要的是，Hazelcast通过提供对开发者友好的Map、Queue、ExecutorService、Lock和JCache接口使分布式计算变得更加简单。例如，Map接口提供了内存中的键值存储，这在开发人员友好性和开发人员生产力方面提供了NoSQL的许多优点。 除了在内存中存储数据外，Hazelcast还提供了一组方便的api来访问集群中的cpu，以获得最大的处理速度。轻量化和简单易用是Hazelcast的设计目标。Hazelcast以Jar包的方式发布，因此除Java语言外Hazelcast没有任何依赖。Hazelcast可以轻松地内嵌已有的项目或应用中，并提供分布式数据结构和分布式计算工具。 Hazelcast 具有高可扩展性和高可用性（100%可用，从不失败）。分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。Hazelcast基于Java实现，并提供C/C++，.NET，REST，Python、Go和Node.js客户端。Hazelcast遵守内存缓存协议

我在区块链会议上就即将到来的公共“分布式云”系统进行了讨论，该系统将主流的公共云平台（如AWS，Azure，Google Cloud，Heroku等）与区块链和P2P网络相结合，比如以太坊，IPFS，EOS，TRON，NEM，NEO，Storj，Sia......为什么？因为分布式组织（DAO）和分布式计算的发展趋势很好，并且行业需要更强大的平台来构建和运行DApp（分布式应用程序）。 让我与大家分享一下我对未来分布式计算网络（也称为“分布式云平台”）的看法。 计算模型和软件系统一直在变化：从独立软件到客户端 - 服务器系统，再到基于云的基础架构和平台。现在，计算模型的下一个重大变革即将到来，它将影响许多行业：分布式，包括一种新型的分布式组织，执行分布式流程，使用分布式数据存储，分布式计算系统，运行和发展分布治理。区块链和其他分布式账本技术（DLT）以及即将推出的分布式数据库，存储系统和其他分布式计算组件将成为新的“分布式云”的核心，这将允许运行分布的IT基础架构和“软件组织” （DAO）在权力下放的治理下没有所有者，没有雇员。由于其透明性，安全性，可追溯性，降低成本和削减中间人的能力，这种区块链和分布运动为许多行业带来了创新和转型：财务，供应链，医疗保健，政府，预测，保险，流动性，投票， IT基础设施，电信和其他。 分布式计算的演变 计算模型发展：单机 - >数据中心 -