分布式技术

阅读本文大概需要 7.2 分钟。 来源：segmentfault.com/a/1190000017346799 1. 分布式应用服务开发的一站式解决方案 Spring Cloud Alibaba Spring Cloud Alibaba 致力于提供分布式应用服务开发的一站式解决方案。 此项目包含开发分布式应用服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。 地址：https://github.com/spring-cloud-incubator/spring-cloud-alibaba 2. 设计语言 & 前端框架 Ant Design Ant Design 是蚂蚁金服开发和正在使用的一套企业级的前端设计语言和基于 React 的前端框架实现。 它的特性：企业级金融产品的交互语言和视觉体系；丰富实用的 React UI 组件；基于 React 的组件化开发模式；背靠 npm 生态圈；基于 webpack 的调试构建方案，支持 ES6。 地址：https://github.com/ant-design/ant-design 3. JDBC

CAP定理： 一个分布式系统 不可能 同时满足 一致性 （C:Consistency）、 可用性 （A:Availability）和 分区容错性 （P:Partition tolerance）这三个基本要求，最多只能满足 其中的两项 。 一致性 在分布式环境中，一致性是指数据在 多个副本之间 是否能够 保持强一致 的特性。 对于一个将数据副本分布在不同节点上的分布式系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是更新前的数据（称为 脏数据 ），这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有 强一致性 （或严格的一致性）。 可用性 可用性是指系统提供的服务必须 一直处于可用 的状态，对于用户的每一个操作请求总是能够在 有限的时间 内 返回结果 ，如果超过了这个时间范围，那么系统就被认为是不可用的。 『有限的时间内』是一个在系统设计之初就设定好的运行指标， 不同的系统会有很大的差别 。比如对于一个在线搜索引擎来说，通常在0.5秒内需要给出用户搜索关键词对应的检索结果。而对应Hive来说，一次正常的查询时间可能在20秒到30秒之间。 『返回结果

原创 | 本体社区成员@澳航CN 原文 | https://m.lcyoufu.com/#/articleDetail?articleid=181149&inviter=N5QP&VNK=e10c7681 区块链技术为解决信任危机而来，但是在发展过程中由于监管缺失，形成了各自为政的局面。 公链作为区块链项目的基础设施，在缺乏有效行业标准和监管措施的大环境下，形成了一个个信息孤岛，以自己认可的方式个性化的野蛮成长着，它们自己制定协议和规则，在自己的链上痛并快乐着。对于用户来说这种封闭的体制造成了非常大的麻烦，互联网之所以能够蓬勃发展得益于信息的共享，但是由于缺乏信任公链项目终止了这种共享，于是互相联通成了迫切的刚需，跨链技术随之而来。 跨链Cross-Chain可以理解为在不同链之间信息互通、价值传递、打破行业壁垒，也可以理解为桥，为不同的链搭建的交流通道，实现信息孤岛的贯穿联通。 对于不同链上的用户来说如果需要转移数字资产，传统的做法是找第三方媒介，用户需要将A链上的资产兑换成第三方媒介的等值资产，在用第三方媒介的等值资产去购买B链上的资产，从而完成资产转移，核心问题是A链和B链没有信任机制不能够直接完成兑换。现实中如果我需要将持有比特币兑换成以太坊，数字货币交易所就是第三方媒介，我需要把钱包中的比特币先充值到该交易所，让后通过交易所来完成兑换，然后在提到自己的钱包

一，Redis作缓存服务器 ​ 本篇博客是接着 上一篇 博客未分享完的技术点。 ​ redis作为缓存服务器是众多企业中的选择之一，虽然该技术很成熟但也是存在一定的问题。就是缓存带来的缓存穿透，缓存击穿，缓存失效问题，继而引用分布式锁。 1.1，缓存穿透 ​ 在如今的项目中大多采用垂直的MVC架构，由service层去调用DAO层，然后DAO层再去查询数据库。而redis作为缓存服务器就是在service层去调用DAO层去查询时先去缓存服务器查询，如果存在则直接返回该数据，否则再去查询数据库。由此可知，这么做大量减少了对磁盘I/O的操作，减轻了数据库的压力。 ​ 现在我们假设一种情况，在数据库中存在有id为1到1000的数据。现在如果有人手动去模拟一个id为1001的请求，那么该数据在缓存服务器中是不存在的，因而便会去查询数据库。那么问题来了，如果是一个大量无效的请求去查询数据库。则势必会对数据库造成难以承受的压力，这种情况就是所谓的缓存穿透。 ​ 那如何解决呢？ ​ 1，将查询到的null值直接保存到缓存服务器中，但是这种做法并不推荐，因为如果是大量不同的请求id同样会去查询数据库。 ​ 2，接口的限流，降级与熔断 ​ 在项目中对于重要的接口一定要做限流，对于以上恶意攻击的请求除了要限流，还要做好降级准备，并且进行熔断，这种做法可以有效控制大量无效请求。 ​ 3，布隆过滤器 ​

1、什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 LInux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。 三、框架与架构 框架是组件的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如：Ruby on Rails、Spring、Laravel、Django等。 框架是规范，架构是结构。 我在这重新定义架构：软件架构指软件系统的顶层结构。 架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系,

前言 一般单机或者单数据库的项目可能规模比较小，适应的场景也比较有限，平台的访问量和业务量都较小，业务ID的生成方式比较原始但是够用，它并没有给这样的系统带来问题和瓶颈，所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景，显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成，而且在分布式环境下这种方式已经无法满足业务的需求，不仅无法完成业务能力，业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次，我们看看大厂都是怎么分析和解决这种ID生成问题的，同时，我也将我之前使用过的方式拿出来对比，看看有什么问题，从中能够得到什么启发。 分布式ID的生成特性 在分析之前，我们先明确一下业务ID的生成特性，在此特性的基础上，我们能够对下面的这几种生成方式有更加深刻的认识和感悟。 全局唯一 ，这是基本要求，不能出现重复。 数字类型，趋势递增 ，后面的ID必须比前面的大，这是从MySQL存储引擎来考虑的，需要保证写入数据的性能。 长度短 ，能够提高查询效率，这也是从MySQL数据库规范出发的，尤其是ID作为主键时。 信息安全 ，如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。 高可用低延时 ，ID生成快，能够扛住高并发，延时足够低不至于成为业务瓶颈。 分布式ID的几种生成办法

一、前言 ​　　随着社会的发展，技术的进步，以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处，那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。 二、背景说明 ​　　我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。 在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统，各自都会有自己的侧重点，例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。 ​　　下面我们来简单模拟一个架构演变过程。 我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系统中来看系统的演变过程。要注意的是接下来的演示模型， 关注的是数据量、访问量提升，网站结构的变化， 而不关注具体业务的功能点。其次，这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。

科技发展带来的挑战 在科技的快速发展推动下，在 IT 领域，企业会面临两个方面的问题。 一是如何实现网站的高可用、易伸缩、可扩展、高安全等目标。为了解决这样一系列问题，迫使网站的架构在不断发展。从单一架构迈向高可用架构，这过程中不得不提的就是分布式。 二是用户规模越来越大，由此产生的数据也在以指数倍增长，俗称数据大爆炸。海量数据处理的场景也越来越多。技术上该如何面对？ 分布式系统 概述 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅。 仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。 分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 初代的 web 服务网站架构往往比较简单，应用程序、数据库、文件等所有的资源都在一台服务器上。 图：互联网初始阶段的网站架构 图：现在互联网网站常用的架构 图：现在互联网网站常用的架构 从分布式系统的概念中我们知道，各个主机之间通信和协调主要通过网络进行，所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中

分布式集群系统下的高可用session解决方案 ----guanfuming 20130216 目前，为了使web能适应大规模的访问,需要实现应用的集群部署. 而实现集群部署首先要解决session的统一，即需要实现session的共享机制。 目前，在集群系统下实现session统一的有如下几种方案： (1) 应用服务器间的session复制共享（如tomcat session共享） (2) 基于cache DB缓存的session共享 应用服务器间的session复制共享 session复制共享，主要是指集群环境下，多台应用服务器之间同步session，使session保持一致，对外透明。 如果其中一台服务器发生故障，根据负载均衡的原理，web服务器（apache/nginx）会遍历寻找可用节点，分发请求，由于session已同步，故能保证用户的session信息不会丢失。 此方案的不足之处： 技术复杂,必须在同一种中间件之间完成(如:tomcat-tomcat之间). session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时, 性能下降更加显著. 这种特性使得web应用的水平扩展受到了限制。 Session内容序列化（serialize），会消耗系统性能。 Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈。

当提起这三个词的时候，是不是很多人都认为分布式=高并发=多线程？ 当面试官问到高并发系统可以采用哪些手段来解决，或者被问到分布式系统如何解决一致性的问题，是不是一脸懵逼？ 确实，在一开始接触的时候，不少人都会将三者混淆，误以为所谓的分布式高并发的系统就是 能同时供海量用户访问 ，而采用多线程手段不就是可以 提供系统的并发能力 吗？ 实际上，他们三个总是相伴而生，但侧重点又有不同。 什么是分布式？ 分布式更多的一个概念， 是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段。 该领域需要解决的问题极多，在不同的技术层面上，又包括： 分布式文件系统、分布式缓存、分布式数据库、分布式计算 等，一些名词如Hadoop、zookeeper、MQ等都跟分布式有关。 从理念上讲，分布式的实现有两种形式： 水平扩展： 当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相当的服务； 垂直拆分： 前端有多种查询需求时，一台机器扛不住，可以将不同的需求分发到不同的机器上，比如A机器处理余票查询的请求，B机器处理支付的请求。 什么是高并发？ 相对于分布式来讲，高并发在解决的问题上会集中一些，其反应的是 同时有多少量 ： 比如在线直播服务，同时有上万人观看。 高并发可以通过分布式技术去解决，将并发流量分到不同的物理服务器上。 但除此之外，还可以有很多其他优化手段