Spring Cloud架构

1 .讨论内容 SOA 、 ESB 、 SAAS 、 PAAS 、 IaaS 、 微 服务 1 ： 互联网 高可用性（HA） 3 ： Spring Cloud 和 dubbo 比较 4 ： Spring Cloud 架构技术描述 5 ： 互联网 高 并发 2 ： 互联话题 ： 独立 访问者数量（ unique visitors ）、 重复 访问者数量（ repeat visitors ）、 页面 浏览数（ page views ）理解 Spring Cloud 架构实现计划 6 ：

2 .SOA( 面向服务的架构 ) 面向 服务的架构（ SOA ）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来 。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 对于一个 SOA 解决方案来说就需要能够满足这些场景的业务需求，能够解决其中的各种技术问题 。 需要解决的基本问题包括 ：   服务的描述问题 ，描述 服务提供哪些功能，适用服务有哪些要求 服务 的注册和查找问题 ，定义好的服务信息在哪发布，如何发布，到哪查找，如何查找 服务 通讯方式 ，包括具体如何向服务发送请求，并获取应答，支持什么样的交互方式。 服务 流程问题 ，对服务流程的灵活定制，执行监控等提供管理 服务 的管理问题 ，服务的提供，撤销，改变这些情况如何进行管理 服务 质量问 题，如何保障安全性，通讯的可靠性，以及事务完整性如何保证 整个 系统的效率问题 ，包括查找效率，通讯效率，服务运行处理效率等 系统 能够提供什么样的开发工具，支持什么样的开发 模式，系统 运行情况是否可以及时了解，是否可以及时获取故障信息，是否可以提供运行状态信息，以利于系统的优化。

3 .ESB（ 企业服务总线 ） ESB 全称为Enterprise Service Bus，即企业服务总线。 它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。 大规模 分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构（ SOA ）是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。 SOA 使用户可以不受限制地重复使用软件、把各种资源互连起来，只要 IT 人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务，那么其他应用系统就可以很方便的使用这些功能服务。

4 .SOA 与 ESB 的区别 SOA 是一种方式或架构，用于具有自服务功能的应用程序，应用程序随后通过用户接口（UI）或经过工作流将其聚合成用户需要的功能。服务不仅是可复用代码的组件，更是运行程序的一部分，客户端可以不必合并它自己的代码直接调用该程序。服务是与业务相关的一个定义。 ESB是用于调节 SOA 中的调用者及服务提供者的机制。它使得调用者在不知道提供者或提供者使用的地址的情况下调用该服务 。 ESB 可在多个提供者、提供者的负载平衡及停止使用提供者（当失效时）之间进行选择，并且基于调用者的需求在提供者之间进行选择，这些提供者提供了各种质量级别的服务。ESB 能够调节同步或异步服务，事实上对于同一服务可以提供同步及异步的访问。 因此 SOA 和 ESB 是相对应的。具备 SOA 的应用程序应当使用 ESB 来调用它的服务。SOA 和 ESB 不必用 Web 服务实现。然而，经常需要 ESB 来调用服务，该服务提供自我描述及发现的能力，这由 Web 服务帮助完成。在 SOA 中经常需要由一种技术实现的调用者，它们用于调用由其它技术实现的服务，这也由 Web 服务帮助完成。所以 SOA、ESB 和 Web 服务都集中于创建这样的领域：一个应用程序中的功能在其它应用程序中也是可用的，本质是复用性。

5 .SAAS ( 软件即服务 ) SaaS 是Software-as-a-Service（软件即服务）的 简称 , 它 与“ on-demand software” （按需软件 ) ， the application service provider(ASP ，应用服务提供商 ) ， hosted software( 托管软件 ) 所具有相似的含义。它是一种通过 Internet 提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。 对 企业来说，SaaS的 优点： ⒈ 从技术方面来看：SaaS是简单的部署，不需要购买任何硬件，刚开始只需要简单注册即可。企业无需再配备IT方面的专业技术人员，同时又能得到最新的技术应用，满足企业对信息管理的需求。 ⒉ 从投资方面来看：企业只以相对低廉的“月费”方式投资，不用一次性投资到位，不占用过多的营运资金，从而缓解企业资金不足的压力；不用考虑成本折旧问题，并能及时获得最新硬件平台及最佳解决方案。 ⒊ 从维护和管理方面来看：由于企业采取租用的方式来进行物流业务管理，不需要专门的维护和管理人员，也不需要为维护和管理人员支付额外费用。很大程度上缓解企业在人力、财力上的压力，使其能够集中资金对核心业务进行有效的运营；SaaS能使用户在世界上都是一个完全独立的系统。如果您连接到网络，就可以访问系统。 对企业来说，SaaS的 缺点 1 .安全性：企业，尤其是大型企业，很不情愿使用SaaS正是因为安全问题，他们要保护他们的核心数据，不希望这些核心数据由第三方来负责。 2 .标准化：SaaS解决方案缺乏标准化。这个行业刚刚起步，没有明确的解决办法，一家公司可以设计建立一个解决方案。鉴于复杂和高度可定制的ERP产品，这是一个冒险的建议。

6 .PAAS( 平台即服务 ) PaaS 是 Platform-as-a-Service 的缩写，意思是平台即服务。 把服务器平台作为一种服务提供的商业模式。通过网络进行程序提供的服务称之为 SaaS(Software as a Service) ，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了 PaaS (Platform as a Service) 。 所谓 PaaS 实际上是指将软件研发的平台（计世资讯定义为业务基础平台）作为一种服务，以 SaaS 的模式提交给用户。因此， PaaS 也是 SaaS 模式的一种应用。但是， PaaS 的出现可以加快 SaaS 的发展，尤其是加快 SaaS 应用的开发速度。在 2007 年国内外 SaaS 厂商先后推出自己的 PAAS 平台。 PaaS区别 简单 地说，PaaS平台就是指云环境中的应用基础设施服务，也可以说是中间件即服务。PaaS平台在云架构中位于中间层，其上层是SaaS，其下层是IaaS[3] 。在传统On-Premise部署方式下，应用基础设施即中间件的种类非常多， 有应用服务器，数据库，ESBs, BPM, Portal,消息中间件，远程对象调用中间件等等。对于PaaS平台，Gartner把它们分为两类，一类是应用部署和运行平台APaaS（application platform as a service)，另一类是集成平台IPaaS（integration as a service）。 人们经常说的PaaS平台基本上是指APaaS，如Force和Google App Engine。 国内 日前上线的中国云应用平台，能够为软件厂商提供领先的IaaS基础平台，使得软件厂商能够将注意力集中在其应用产品的云化之上，而将对基础资源的需求，包括云服务器、云存储、云监控等完全依托在理念领先、技术成熟、安全可靠的IaaS平台上。

7 .IaaS ( 基础设施即服务 ) IaaS （ Infrastructure as a Service ），即基础设施即服务。 消费者通过 Internet 可以从完善的计算机基础设施获得服务。这类服务称为基础设施即服务。基于 Internet 的服务（如存储和数据库）是 IaaS 的一部分。 Internet 上其他类型的服务包括平台即服务（ Platform as a Service ， PaaS ）和软件即服务（ Software as a Service ， SaaS ）。 PaaS 提供了用户可以访问的完整或部分的应用程序开发， SaaS 则提供了完整的可直接使用的应用程序，比如通过 Internet 管理企业资源。 根据 NIST （ NationalInstituteofStandardsandTechnology ，美国国家标准与技术研究院）的权威定义，云计算的服务模式有 SPI （即 SaaS 、 PaaS 和 IaaS ）这三个大类或层次。这是目前被业界最广 泛认同的划分。 PaaS 和 IaaS 源于 SaaS 理念。 PaaS 和 IaaS 可以直接通过 SOA/Web Services 向平台用户提供服务， 也可以作为 SaaS 模式的支撑平台间接向最终用户 服务 IaaS 中间件 （包括 HPC/ Gri 中间件 ,PVM/MPI, 机群 / 集群 , Beowulf,DRS 作业调度 , 并行文件系统等 ） 云系统 （效用计算机 SaaS BI/BPM,BSS/OSS,WS/SOA/API ） PaaS 中间件 （包括应用服务器 MQ/ESB/SOA, 多层次多租户 SaaS 模式支撑 , Hypervisor,OSGI 等）

8 .IaaS 、 PaaS 、 SaaS 1. SaaS ： 提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可以在各种设备上通过客户端界面访问，如浏览器。消费者不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等等； 2. PaaS ： 提供给消费者的服务是把客户采用提供的开发语言和工具（例如 Java ， python, .Net 等）开发的 或收购的应用程序部署到供应商的云计算基础设施上去。客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但客户能控制部署的应用程序，也可能控制运行应用程序的托管环境配置； 3. IaaS ： 提供给消费者的服务是对所有计算基础设施的利用，包括处理 CPU 、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。消费者不管理或控制任何云计算基础设施，但能控制操作系统的选择、存储空间、部署的应用，也有可能获得有限制的网络组件（例如路由器、，防火墙，、负载均衡器等）的控制。

9 .SOA 和 SaaS 的区别 1 . SOA包括了关于软件是如何被架构起来的东西，而SaaS是关于软件是如何被应用的。 　　2. 在SaaS当中，应用程序可以像任何服务一样被传递，就像你家中电话的语音一样，看起来似乎就是为你的需求量体裁衣得到的。而SOA的定义和这个无丝毫的联系。SOA支持的服务，都是些离散的可以再使用的事务处理，这些事务处理合起来就组成了一个业务流程，是从基本的系统中提取出来的抽象代码。 　　3. SOA是一个框架的方法，而SaaS是一种传递模型。 　　4. 通过SaaS传递Web服务并不需要SOA。 　　5. SaaS主要是指一个软件企业向其它企业提供软件服务。而SOA一般是企业内部搭建系统的基础。SaaS注重的是提供服务的思维。而SOA注重的是实现服务的思维。

10 .什么是微服务架构 微 服务架构模式（ Microservice Architect Pattern ）。近 两年在 服务 的疯狂增长与云计算技术的进步，让微服务架构 受到重点 关注 微 服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 微服务架构优势 首先 简单介绍了微服务（ Microservices ）的内涵及优势，他表示，微服务架构的本质，是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题 。 微服务架构将服务拆分，分别采用相对独立的服务对各方面进行管理，彼此之间使用统一的接口来进行交流，架构变得复杂，优势也很明显 ： 复杂 度可控 ：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

11 .什么是微服务架构 微服务架构优势 独立 部署 ：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 技术 选型灵活 ：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。 容错 ：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。 扩展 ：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

12 .SOA 和微服务架构的区别 如果 一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。 微 服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。 首先 对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的 其次 微 服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。 微 服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。

13 .互联网高并发相关名词 页面 浏览数（ page views ） 独立访问者数量（ unique visitors ） 重复访问者数量（ repeat visitors ） 每个访问者的页面浏览数（ Page Views per user ） 唯一身份浏览量（ Unique PageViews ）

14 .高并发 之前 我将高并发的解决方法误认为是 线程或者是队列可以解决 ，因为高并发的时候是有很多用户在访问，导致出现系统数据不正确、丢失数据现象，所以想到 的是用队列解决，其实队列解决的方式也可以处理，比如我们在竞拍商品、转发评论微博或者是秒杀商品等，同一时间访问量特别大，队列在此起到特别的作用，将 所有请求放入队列，以毫秒计时单位，有序的进行，从而不会出现数据丢失系统数据不正确的情况。 经过 查资料，高并发的解决方法有俩种， 一种是使用缓存、另一种是使用生成静态页面 ；还有就是从最基础的地方优化我们写代码减少不必要的资源浪费：( 1.不要频繁的new对象,对于在整个应用中只需要存在一个实例的类使用单例模式.对于String的连接操作,使用StringBuffer或者StringBuilder.对于utility类型的类通过静态方法来访问。 2. 避免使用错误的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做条件判断,尽量使用比的条件判断方式.使用JAVA中效率高的类,比如ArrayList比Vector性能好。)

15 .互联网 高并发系统 - 需要解决的问题 一 ：应用缓存 二 ： HTTP 缓存 三 ：多级缓存 四 ：池化 五：异步并发 六：扩容 七：队列

16 .高并发 - 应用 缓存 堆缓存 使用 Java 堆内存来存储缓存对象。使用堆缓存的好处是没有序列化 / 反序列化，是最快的缓存。缺点也很明显，当缓存的数据量很大时， GC （垃圾回收）暂停时间会变长，存储容量受限于堆空间大小。一般通过软引用 / 弱引用来存储缓存对象，即当堆内存不足时，可以强制回收这部分内存释放堆内存空间。一般使用堆缓存存储较热的数据。有 Guava Cache 、 Ehcache 3.x 、 MapDB 实现 堆外缓存 即缓存数据存储在堆外内存，可以减少 GC 暂停时间（堆对象转移到堆外， GC 扫描和移动的对象变少），但是，读取数据时需要序列化 / 反序列化，因此会比堆缓存要慢很多。有 Ehcache 3.x 、 MapDB 实现 磁盘缓存 即缓存数据存储在磁道上，在 JVM 重启时数据还存在的，而堆缓存 / 堆外缓存数据会丢失，需要重新加载。 有 Ehcache 3.x 、 MapDB 实现

17 .高并发 - 应用 缓存 分布式缓存 之前缓存提到是进程内缓存和磁盘缓存，在多 JVM 实例的情况下，会存在两个问题： 1 、单机容量问题； 2 、数据一致性问题（多台 JVM 实例的缓存数据不一致怎么办 ？ ），这个问题不用纠结，既然数据允许缓存，则表示允许一定时间内的不一致，因此可以设置缓存数据的过期时间来定期更新数据； 3 、缓存不命中时，需要回源到 DB/ 服务请求多变问题：每个实例在缓存不命中的情况下都会回源到 DB 加载数据，因此多实例后 DB 整体的访问量变多了解决办法是可以使用如一致性哈希分片算法。因此，这些情况可以考虑使用分布式缓存来解决。 可以使用 ehcache –clustered( 配合 Terracotta server) 实现 JAVA 进程间分布式缓存。最好的办法是使用 redis 实现分布式缓存。

18 .高并发 - HTTP 缓存 浏览器 缓存是指当我们使用浏览器访问一些网站页面或者 http 服务时，根据服务端返回的缓存设置响应头将响应内容缓存到浏览器，下次可以直接使用缓存内容或者仅需要去服务端验证内容是否过期即可。这样的好处可以减少浏览器和服务端之间来回传输的数据量，节省带宽提升性能。 解决办法： 内容 不需要动态（计算、渲染等）速度更快，内容越接近于用户速度越快。像 apache traffic server 、 squid 、 varnish 、 nginx 等技术都可以来进行内容缓存。还有 CDN 就是用来加速用户访问的： 即用户首先访问到全国各地的 CDN 节点（使用如 ATS 、 Squid 实现），如果 CDN 没命中，会回源到中央 nginx 集群，该集群如果没有命中缓存（该集群的缓存不是必须的，要根据实际命中情况等决定），最后回源到后端应用集群。

19 .高并发 - 多级缓存（分布式缓存）

20 .高并发 - 池 化 在应用系统开发过程中，我们经常会用到池化技术，如对象池、连接池、线程池等，通过池化来减少一些消耗，以提升性能。对象池通过复用对象从而减少创建对象、垃圾回收 的开销。但是，池化不能太大，太大会影响 GC 时的扫描时间。连接池如数据库连接池、 Redis 连接池、 Http 连接池，通过复用 TCP 连接减少创建和释放连接的时间来提升性能。线程池也是类似的，通过复用线程提升性能。也就是说池化的目的就是通过复用技术提升性能。

21 .高并发 - 扩容 1 、读写分离： 当数据库访问量还不是很大的时候，我们可以适当增加服务器，数据库主从复制的方式将读写分离 2 、垂直分区： 当写入操作一旦增加的时候，那么主从数据库将花更多的时间的放在数据同步上，这个时候服务器也是不堪重负的；那么就有了数据的垂直分区，数据的垂直分区思路是将写入操作比较频繁的数据表，如用户表 _user, 或者订单表 _orders, 那么我们就可以把这个两个表分离出来，放在不同的服务器，如果这两个表和其他表存在联表查询，那么就只能把原来的 sql 语句给拆分了，先查询一个表，在查询另一个，虽然说这个会消耗更过性能，但比起那种大量数据同步，负担还是减轻了不少； 3 、水平分区： 但是往往事情不尽人意，可能采取垂直分区能撑一段时间，由于网站太火了，访问量又每日 100w, 一下子蹦到了 1000w, 这个时候可以采取数据的进行分离，我们可以根据 user 的 Id 不同进行分配，如采取 %2 的形式，或者 %10 的形式，当然这种形式对以后的扩展有了很大的限制，当我由 10 个分区增加到 20 个的时候，所有的数据都得重新分区，那么将是一个的很庞大的计算量；以下提供几种常见的算法：    哈希算法： 就是采用 user_id % 的方式 ;    范围：可以根据 user_id 字符值范围分区，如 1-1000 为一区， 1001-2000 则是另一个区等；    映射关系： 就是将 user_id 存在的所对应的分区放在数据库中保存，当用户操作时先去查询所在分区，再进行操作；

22 .高并发 - 扩容分布式数据库 4 、分布式数据库（终极方案）： TDSQL 架构采用自动 扩容 机制、 分表 逻辑、 扩容 流程、 容灾 机制、 强同步 方案解决分布式数据库扩容方案

23 .高并发 - 扩容分布式数据库 系统由三个模块组成：Scheduler、Agent、网关，三个模块的交互都是通过ZooKeeper完成，极大简化了各个节点之间的通信机制，相对于第二代HOLD的开发简单了很多。 Scheduler作为集群的管理调度中心，主要功能包括： 1 、管理 set，提供创建、删除set、set内节点替换等工作 ； 2 、所有 的DDL操作统一下发和调度 ； 3 、监控 set内各个节点的存活状态，当set内主节点故障，发起高一致性主备切换流程 ； 4 、监控 各个set的CPU、磁盘容量、各个表的资源消耗情况，必要的时候自动发起扩容流程 ； 5 、Scheduler 自身的容灾通过ZooKeqzer的选举机制完成，保证中心控制节点无单点 。 Agent模块负责监控本机MySQL实例的运行情况，主要功能包括： 1 、用 短连接的方式周期性访问本机的MySQL实例，检测是否可读、可写，若发生异常，会将异常信息上报到ZooKeeper，最终会由上面描述的Scheduler模块检测到这个异常情况，从而发起容灾切换 ； 2 、检测 主备复制的执行情况，会定期上报主备复制的延时和延迟的事务数，若发生了主备切换，自动向新主机重建主备，因此MySQL的主备不需要DBA干预，对于新增的实例会自动采用xtrabackup通过主机自动重建数据 ；

24 .高并发 - 扩容分布式数据库 3 、检测 MySQL实例的CPU利用率和各个表的请求量、数据量、CPU利用率，上报到ZooKeeper，ZooKeeper通过全局的资源情况抉择如何扩容、缩容 ； 监控是否有下发到自身的扩容任务，如有则会执行扩容流程（下面会有描述）； 监控是否要发生容灾切换，并按计划执行主备切换流程 。 网关基于MySQL Proxy开发，在网络层、连接管理、SQL解析、路由等方面做了大量优化，主要特点和功能如下： 1 、解析SQL，将识别出的DDL语句直接存到ZooKeeper，让Keeper来统一调度； 2 、Watch ZooKeeper的路由信息，拉取最新的路由表保存到本地文件和内存； 3 、将SQL请求路由到对应的set，支持读写分离； 4 、对接入的IP、用户名、密码进行鉴权； 5 、记录完整的SQL执行信息，与秒级监控平台对接完成实时的SQL请求的时耗，成功率等指标监控分析； 6 、对count、distinct、sum、avg、max、min、order by、group by等聚合类SQL一般需要访问后端的多个set，网关会分析结果并做合并再返回，暂不支持跨set join和分布式事务； 7 、网关无状态，既支持与业务部署到一起，也可以独立部署（可通过TGW或者LVS做容灾）。

25 .高并发 - 扩容（ Canal 分布式数据库同步 系统 ） 1. 基于Canal开源产品，获取数据库增量日志数据。 2. 典型管理系统架构，manager(web管理)+node(工作节点) a. manager运行时推送同步配置到node节点 b. node节点将同步状态反馈到manager上 3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作.

26 .高并发 - 队列应用场景 1 、异步处理： 使用队列的一个主要原因是进行异步处理，比如用户注册完成后，需要发送注册成功邮件 / 新用户积分 / 优惠卷等；缓存过期时，先返回过期数据，然后异步更新缓存、异步写日志等。 2 、系统解耦： 比如用户支付完成订单后，需要通知生产配货系统、发票系统、库存系统、推荐系统、搜索系统等进行业务处理。 3 、数据 同步 ： 比如想把 mysql 变更的数据同步到 Redis ，或者将 mysql 数据同步到 mongodb , 或者让机房之间的数据同步，或者主从数据同步等，有相关软件： databus 、 canal 、 otter 等。使用数据总线队列进行数据同步的好处是可以保证数据修改的有序。 4 、流量削峰： 系统的瓶颈一般在数据库上，比如扣减库存、下单等，此时可以考虑使用队列将变更请求暂时放入队列，通过缓存 + 队列暂存的方式将数据库流量削峰。同样，对于秒杀系统，下单服务会是该系统的瓶颈，此时可以使用队列进行排队和限流，从而保护下单服务，通过队列暂存或者队列限流进行流量削峰

27 .高并发 - 队列（ Canal ） 1 、 Canal 同步缓存 2 、 Canal 下发任务给消息队列

28 .高 可用 什么是高可用性 高可用性（HA） 系统 是目前企业防止核心计算机系统因故障停机的最有效手段。 高可用性（HA）的功能 1 、软件故障监测与排除 2 、备份和数据保护 3 、管理站能够监视各站点的运行情况，能随时或定时报告系统运行状况，故障能及时报告和告警，并有必要的控制手段 4、 实现错误隔离以及主、备份服务器间的服务切换 HA的工作 方式： HA有主从方式和双工方式两种工作模式 高 可用性方案则利用更少的冗余部件同时由软件检测故障，一旦故障发生立即隔离损坏部件，通过提供故障恢复实现最大化系统和应用的可用性。 容错 技术随着处理器速度的加快和价格的下跌而越来越多地转移到软件中。未来容错技术将完全在软件环境下完成，那时它和高可用性技术之间的差别也就随之消失了。

29 .互联网 高 可用性（HA）系统 - 需要解决的问题 一 ：负载均衡与反向代理 二 ：隔离 三 ：限流 四 ：降级 五：超时与重试 六：回滚 七：压力测试与应急预案