分布式架构

对于大型的互联网业务来说，消息系统是必不可少的基础服务。 子柳 在《淘宝技术这十年》中为大家展示了阿里消息系统架构的概貌，作为集团业务使用的核心基础服务，目前消息系统现在可以承受每天几百亿规模的请求，并在历年的双十一、双十二大促中承受住抗住了更加严峻的考验，消息系统背后的中间件团队还陆续开源了诸如 MetaQ 、 RocketMQ 等项目。近期，InfoQ 采访了阿里消息中间件团队消息和分布式数据层负责人王晶昱（花名：沈询），话题涉及案例中间件系统的选型、系统扩容与数据一致性、团队文化等内容。 InfoQ ：对于阿里的消息中间件系统，大家所广泛了解的是 @ 子柳 在《淘宝技术这十年》中介绍的 Notify ，但是从最近的阿里的开源计划中，我们经常看到 MetaQ / RocketMQ ，在阿里内部 Notify 和 MetaQ 是怎样的关系？我看到早期的 MetaQ 是采用的 Kafaka 的设计思路，那么可能大家就比较好奇 “ 问什么要重复造轮子 ” ，能不能介绍这个方面的考虑以及所做的工作？ 沈询： 要讲明白这个问题，就需要从产品的实际需求角度入手开始做个介绍了。Notify作为一个已经存在了5年多的消息产品，被广泛的应用在整个阿里巴巴集团的大部分消息通信领域。它的核心特性是： 提供事务支持、不保证消息顺序、消息可能会重复、推模型。 因为淘宝是个交易类网站

目前项目采用nginx+tomcat来做负载均衡，缺少一个分布式任务调度配置。任务调度在整个系统中是单点故障。为了解决这个问题，研究了一下zookeeper和redis。大家一致的解决方案是用分布式锁。通过zookeeper或者redis来构建一个锁实现。所有系统节点都能获取到这个锁的状态，作为一个共享锁，为系统调度提供分布式部署。 因为我的系统架构是spring架构。为了减少代码对系统的侵入，扩展spring的任务调度。将分布式任务调度机制写入自定义任务调度中。 <task:scheduled-tasks scheduler="zkScheduleManager"> <task:scheduled ref="taskObj" method="print" fixed-rate="5000"/> </task:scheduled-tasks> zkScheduleManager继承spring的 org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler; 在各个调度方法中写入分布式任务调度机制。 代码量比较大，下边说一下思路，后续把代码补上。 zookeeper维护server task两个文件夹。server存放连接的节点，task存放注册的任务 为了防止羊群效应每个服务器上维护一个EPHEMERAL

最近一段时间在研究数据库的分布式部署，但是并不是所有的数据库本身都支持分布式，那么怎么办呢。 本人自己没有用过分布式的数据库，根据自己的想到一种简单分布式的架构，来进行分布式的部署。 现在先上图， 大概的想法是在数据库外面多加一次 分布式引擎和引擎数据库，来实现对多个数据库的管理， 首先我们来说一下此种方案的 可行性 ，它是基于原来数据库的基础上在搭建平行的数据库来分摊压力，而分布式引擎的作用则是处理主程序对数据库的请求，并返回请求的结果的， 此种方案的难点和核心点在于分库，依据什么来分库会影响到最终搭建成的系统的运行效率，一个好的依据可以把原来的压力平均分摊给各个数据库（ 最好情况 ），而一个差的依据会导致压力集中到分布式引擎，导致压力剧增，运行效率和承受压力比原来还大， 在下以为分库的依据有以下几点需要注意的地方， 1.分开的数据库数据要平均，尽量每个数据库的数据量是相近的。 2. 面向客户的数据尽量是连续，即主程序一次查询出来面向客户的数据是从1个或者2个数据库就能查询出来的，也不是是1个表的数据只存在其中的一个数据库中，而是面向客户的数据只是查询分页的20条至50条直接，要尽量保证这些数据是在1个数据库就能全取出来的。 3.有业务关联性的数据最好都放在一个数据库中，比如这是一个管理系统，那么本系统的流程中的所有相关数据最好是放在一个库中。 4

  随着互联网+、智能制造等大数据应用的发展，传统的企业信息化单体架构必定绕不过以下两个坎： 单机资源瓶劲造成系统响应慢，需要高成本升级硬件来解决； 单机故障造成系统不可用，需要较长的时间来恢复故障。   所以将来的企业信息化基础架构必定是分布式的，AppBoxFuture设计之初就确立了必须满足 简单、低成本 的分布式架构原则，能够利用普通硬件构建具备横向扩展能力的集群。作者最近在设计与实现集群的运维管理功能，下面让我们来体验已实现的部分功能。 一、测试环境 二、创建集群 1. 启动集群： 在VM1上执行： sudo ./appbox --init=10.211.55.3:9000 --peer=1.1.1 在VM2及VM3分别执行： sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.2 sudo ./appbox --join=10.211.55.3:9000 --peer=1.1.3 执行完后，打开浏览器输入网址“ http://任意节点:5000/ops”进入运维管理登录界面，用户名：Admin 密码：760wb，可以看到集群包含3个节点，其中第一个是元数据节点(MetaNode)。 运维管理系统由框架自身实现，可以自由修改相关模型进行自定义。 2. 提升副本因子： 依次点击“SetAsMeta

随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。本文主要简单介绍了分布式系统的概念、分布式系统的特点、常用的分布式方案以及分布式和集群的区别等。 一、集中式系统 在学习分布式之前，先了解一下与之相对应的集中式系统是什么样的。 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。现在的银行系统，大部分都是这种集中式的系统，此外，在大型企业、科研单位、军队、政府等也有分布。集中式系统，主要流行于上个世纪。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 二、分布式系统(distributed system) 在《分布式系统概念与设计》一书中，对分布式系统做了如下定义： 分布式系统是一个硬件或软件组件分布在不同的网络计算机上

分布式和集群 分布式和集群是不⼀样的，分布式⼀定是集群，但是集群不⼀定是分布式（因为集群就是多个实例⼀起 ⼯作，分布式将⼀个系统拆分之后那就是多个实例；集群并不⼀定是分布式，因为复制型的集群不是拆 分⽽是复制） 第⼀部分 ⼀致性Hash算法 Hash算法，⽐如说在安全加密领域MD5、SHA等加密算法，在数据存储和查找⽅⾯有Hash表等, 以上 都应⽤到了Hash算法。 为什么需要使⽤Hash? Hash算法较多的应⽤在数据存储和查找领域，最经典的就是Hash表，它的查询效率⾮常之⾼，其中的 哈希算法如果设计的⽐较ok的话，那么Hash表的数据查询时间复杂度可以接近于O(1)，示例 需求：提供⼀组数据 1,5,7,6,3,4,8，对这组数据进⾏存储，然后随便给定⼀个数n，请你判断n是否存在 于刚才的数据集中？ list:List[1,5,7,6,3,4,8] // 通过循环判断来实现 for(int element: list) { if(element == n) { 如果相等，说明n存在于数据集中 } } 以上这种⽅法叫做顺序查找法 ：这种⽅式我们是通过循环来完成，⽐较原始，效率也不⾼ ⼆分查找：排序之后折半查找，相对于顺序查找法会提⾼⼀些效率，但是效率也并不是特别好 我能否不循环！不⼆分！⽽是通过⼀次查询就把数据n从数据集中查询出来？？？可以！ 定义⼀个数组，数组⻓度

转载自： https://hadyang.github.io/interview/docs/architecture/distributed/zk/ 分布式应用 分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说， 对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成 。 通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为 集群 ，而在集群中运行的每台机器被称为 节点 。 分布式应用的优点 可靠性：单个或几个系统的故障不会使整个系统出现故障。 可扩展性：可以在需要时增加性能，通过添加更多机器，在应用程序配置中进行微小的更改，而不会有停机时间。 透明性：隐藏系统的复杂性，并将其显示为单个实体/应用程序。 分布式应用的挑战 竞争条件：两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。 死锁：两个或多个操作等待彼此无限期完成。 不一致：数据的部分失败。 ZooKeeper基础 Apache ZooKeeper是由集群（节点组）使用的一种服务，用于在自身之间协调，并通过稳健的同步技术维护共享数据

1. 概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

GitHub：https://github.com/actiontech/dble 官方中文文档：https://actiontech.github.io/dble-docs-cn/ 一、环境准备 DBLE项目资料 安装JDK环境 二、安装DBLE 三、配置DBLE 应用场景一：数据拆分 应用场景二：读写分离 四、总结 环境准备 DBLE 项目资料 DBLE 是企业级开源分布式中间件，江湖人送外号 “MyCat Plus” ；以其简单稳定，持续维护，良好的社区环境和广大的群众基础得到了社区的大力支持； DBLE官方网站： https://opensource.actionsky.com 可以详细了解DBLE的背景和应用场景，本文不涉及到的细节都可在官方文档获得更细节都信息；对于刚了解到同学，可以以本文为快速入门基础 DBLE 官方项目： https://github.com/actiontech/dble 如对源码有兴趣或者需要定制的功能的可以通过源码编译安装 DBLE 下载地址： https://github.com/actiontech/dble/releases DBLE 官方社区交流群 ：669663113 安装 JDK 环境 DBLE 是使用 java 开发的，所以启动 DBLE 需要先在机器上安装 java 版本 1.8 或以上，并且确保 JAVA_HOME

当设计一个分布式系统或微服务架构系统时，一般需要设计和开发一些协调服务。Apache ZooKeeper是一个分布式、开源的分布式应用协调服务，也可理解成一个为分布式应用提供一致性服务的应用程序，主要作用可简化分布式系统搭建及缩短开发周期。ZooKeeper是目前常用的开源解决方案之一。 本文主要针对ZooKeeper的安装部署、应用场景、开发对接API等，作简单入门级整理介绍，方便开发人员后续深入研究。 ZooKeeper是什么？ ZooKeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题。提供基于类似于文件系统的目录节点树方式的数据存储，ZooKeeper的作用主要是用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。 ZooKeeper 虽然是一个针对分布式系统的协调服务，但它本身也是一个分布式应用程序。ZooKeeper 遵循一个简单的客户端-服务器模型。 ▲ ZooKeeper 的客户端-服务器架构 ZooKeeper 有一个类似于文件系统的数据模型，由 znodes 组成。 每个 ZooKeeper 服务器还在磁盘上维护了一个事务日志，记录所有的写入请求。 在启动 ZooKeeper 服务时，集合体中的某个节点被选举为领导者；节点数量应该是奇数。 Zookeeper 从设计模式角度来看