分布式技术

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

　　Java能力和面试能力，这是两个方面的技能，可以这样说，如果不准备，一些大神或许也能通过面试，但能力和工资有可能被低估。再仔细分析下原因，面试中问的问题，虽然在职位介绍里已经给出了范围，但针对每个点，面试官的问题是随机想的，甚至同一个面试官在两场相似的面试里，提的问题也未必一样。 　　也就是说，如果让面试官自由提问，那么一旦问到你不熟悉的点，你可能就答不上，如果运气不好，再外加上不知道面试引导技巧等因素，真有可能面试官的提问全落在你不熟悉的范围内，这样就非常可惜了。与其这样，还不如事先准备外带面试引导，这样或许你的能力未必行，但你可以尽可能地通过引导展示你的亮点，从而提升面试通过的可能性。在本文里，就将讲述事先准备Java亮点和面试中引导面试官提问的技巧。 　　根据职位介绍微调简历，这关系到能否有面试机会 　　虽然这点和本文的主题无关，但如果没有面试机会，那甚至无法展示引导技能，所以还是来啰嗦一下。筛选简历的人，除了会看学历专业等硬条件外，更会看相关经验的商业项目经验，这在职位介绍上一定能体现出来，比如初级开发，一般需要SSM等框架的1年经验，高级开发一般需要3年，再外带些诸如Netty，数据库调优等方面的技能。 　　如果看到一份简历上，没有明显的相关商业项目经验(学习项目不算)，那么这份简历甚至没面试机会，这就是为什么很多初级开发简历大多石沉大海的原因

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

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

历史 自从20世纪60年代大型主机被发明出来以后，凭借其超强的计算和I/O处理能力以及在稳定性和安全性方面的卓越表现，在很长一段时间内，大型主机引领了计算机行业以及商业计算领域的发展。由于大型主机卓越的性能和良好的稳定性，其在单机处理能力方面的优势非常明显，使得IT系统快速进入了集中式处理阶段，其对应的计算机系统称为集中式系统。 但从20世纪80年代以来，随着微型计算机的出现，越来越多廉价的PC机成为了各大IT企业架构的首选，分布式的处理方式越来越受到业界的青睐，计算机系统正在经历一场前所未有的从集中式到分布式架构的变革。 主要有以下几点原因： 大型主机的人才培养成本非常高，通常一台大型主机汇集了大量精密的计算机组件，操作非常复杂，这对一个运维人员掌握其技术细节提出了非常高的要求。 大型主机也是非常昂贵的，通常一台配置较好的IBM大型主机，其售价达到上百万美元甚至更高，因此也只有像政府、金融和电信等企业才有能力采购大型主机。 集中式有非常明显的单点问题，大型主机虽然在性能和稳定性方面表现卓越，但并不代表其永远不会出故障。一旦一台大型主机出现了故障，那么整个系统将处于不可用的状态，后果相当严重。 随着业务的不断发展，用户访问量迅速提高， 计算机系统的规模也在不断扩大，在单一大型主机上进行扩容往往比较困难。 随着PC机性能的不断提升和网络技术的快速普及，大型主机的市场份额变得越来越小

一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题 随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。

关于分布式系统的连环炮 为什么要进行系统拆分？拆分后不用dubbo可以吗？ 系统越来越复杂，维护起来非常麻烦，各种冲突，各种合并，非常耗费时间，之间依赖复杂，异常处理起来非常麻烦，各种痛苦 拆分后每个服务都是一个单独的模块，一个人维护一个服务，每个机器部署一个服务， 避免了很多冲突，代码清爽 可以，但是我们如果调用其他服务的接口时会有很多问题需要考虑，负载均衡，超时重试等等一系列问题，dubbo是一个rpc框架，就是本地接口 进行调用，底层会帮我们处理负载均衡，服务上下线自动感知，超时重试等，不需要我们自己去考虑，直接使用就可以了 说一下dubbo的工作原理？注册中心挂了可以继续通信吗？说说一次rpc请求流程？ dubbo一共分为10层，provider层，如果一个服务A部署在三台机器上，每台机器有各自的ip，服务会将自己的信息在注册中心进行注册，这样注册中心就有了这个服务的注册信息。 这时一个用户请求发送过来，然后消费者会连接注册中心拉取自己需要调用的服务，消费者就会获取到注册中心里需要调用的服务的信息，这时消费者和服务提供者都会有dubbo 生成的代理，消费者的代理通过负载均衡找到服务A其中的个代理获取需要的数据，服务A返回数据给自己的代理，服务A的代理在返回给消费者的代理，然后返回给消费者，最后返回 给用户，这样就是一个dubbo的执行流程。 如果注册中心挂了还是可以继续通信

据 IDC 最新报告预测，2022 年中国 50% 以上的组织都将成为数字化坚定者，依靠新的商业模式、数字化产品与服务实现业务增长。 面对数字化转型的时代浪潮，青小云为大家准备了一份硬核大礼 —— 《数字化转型之路》 ，包含 基础设施 、 业务架构 、 解决方案 到 行业实践 、 未来探索 五个部分，该系列 是对数字化转型理论与具体实践路径的系统梳理 ，希望帮助读者全面准确把握数字化转型发展趋势与前沿技术，促进企业与组织能够在变革的数字化世界中创造更大的价值，实现更强健的生命力。 今天与大家分享的是《数字化转型之路》中基础设施篇——QingStor®️ 云时代企业级分布式存储平台。 以下是 分享正文 首先为大家简单介绍青云在存储上的思考和产品线的布局，让大家对青云的存储、特别是软件定义存储有一个全面的了解。 市场发展趋势 这是 IDC 2018 年的报告，可以看出 2018 年软件定义存储领域的增长比较快，同比增长率超过 50%，往前追溯一年，2017 年同比 2016 年是超过百分百的增长率。 在 SDS 市场中，按存储接口领域区分，主要分为分布式块存储、分布式文件存储和分布式对象存储。在这三种接口里占比最大的是分布式文件存储，2018 年大概有六成市场属于分布式文件存储，块存储大概是两成左右，对象存储也是两成左右。 这是三种存储分别在 2018 年的增长态势

前言 文件系统是最常用的数据存储形式，所以，常用Linux操作系统的用户必然知道ext4、xfs等单机文件系统，用Windows操作系统的用户也都知道NTFS单机文件系统。各种业务场景下，不同的数据都存储于文件系统之上，大量业务逻辑就是基于文件系统而设计和开发的。提供最常用的存储访问方式，这是我们做文件系统的出发点之一。 另一方面，单机文件系统有其明显限制，主要是容量、文件数量限制，以及可靠、可用性限制。单机文件系统毕竟存储空间有限，且掉电或坏盘等故障会带来数据不可达或丢失。通过分布式文件系统解决这些问题，这是我们的出发点之二。 但做分布式文件系统会面临很多挑战，也会面临非常多的选择。 Google GFS论文面世之后，Hadoop HDFS随之诞生，HDFS的选择是处理大文件，面向MapReduce这种非在线数据分析业务，重吞吐而非延时，对HDFS内部存储的数据进行访问，需要借助其提供的专有命令行和SDK，意味着它并不是一个通用型的文件系统。它的主要架构是元数据服务（本文统一用MetaData Service的缩写MDS来指代元数据服务）和数据服务（本文统一用Data Storage Service的缩写DSS来指代数据服务），其中MDS是单点的，单点的MDS能做出一致的决策，为了保证MDS可靠性，一般会选择再做一个备份。HDFS的DSS则可以是很多个。因为文件大小和形式固定