分布式架构

马总在2003年4月7日秘密叫来阿里巴巴的十位员工，来到杭州一个隐秘的毛坯房，要求他们在一个月左右的时间内做出一个C2C网站。结果当然还是直接买的快，一个基于LAMP架构的网站，原名是PHPAuction，老美开发的一个拍卖网站。当然必须要做修改才能用。 2003年底，淘宝注册用户23万，PV 31万/day，半年成交额3371万 很显然MySQL无法撑得起如此大的访问量，数据库瓶颈出现了。幸好阿里的DBA队伍足够强大，他们使用Oracle替代了MySQL。Oracle那时就已经有了强大的并发性访问设计――连接池，从连接池取连接的耗费比单独建立连接少很多。但是PHP当时并没有官方提供支持语言连接池特性，于是多隆前辈用Google（不会是Baidu）搜到了一个开源的SQL Relay，于是数据库软件方面的瓶颈暂时解决了。 随之而来的是面临硬件性能瓶颈，阿里买了EMC的SAN存储设备，加上Oracle高性能RAC，硬件容量也暂时没问题了。 因为SQL Relay的问题实在过于严重，2004年于是淘宝终于做出了跨时代的决策――使用Java重写网站。 淘宝请了Sun的高级工程师来帮忙做Java架构。那么他们是如何做到修改编程语言而不改变网站使用呢――模块化替换，今天写好了A模块，另开一个新域名，将连接指向该模块，同时别的模块不变，等到全部模块完成的时候，原域名放弃

最新后端架构师技术图谱 深呼吸，慢慢学 ，技术长路漫漫… 数据结构 二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B-，B+，B*树 LSM 树 队列 集合 链表、数组 字典、关联数组 树 BitSet 常用算法 KPM 算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 排序、查找算法 布隆过滤器 字符串比较 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 & 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 事务 ACID 特性 事务的隔离级别 多线程 线程安全 一致性、事务 锁 操作系统 计算机原理 进程 线程 协程 Linux 设计模式 康威定律 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 责任链模式 MVC IOC AOP UML 微服务思想 运维 & 统计 & 技术支持 OpenStack Docker KVM Xen OpenVZ TDD 理论 单元测试 压力测试 全链路压测 A/B Test Ansible puppet chef Jenkins

集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。 分布式 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。 节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中，一个节点表示的是一个操作系统上的进程。 副本机制 副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个节点的数据丢失时，可以从副本上读取到数据。（张三请假了，李四负责顶替张三的工作）数据副本是分布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现服务的高可用方案。 中间件 中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分。 一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中，开发模式、技术架构等都会发生非常大的变化。 阶段一，单应用架构

事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 3.幻读 第一个数据正在查询某一条数据，这时，另一个事务又插入了一条符合条件的数据，第一个事务在第二次查询符合同一条件的数据时，发现多了一条前一次查询时没有的数据，仿佛幻觉一样，这就是幻读 不可重复读是指在同一查询事务中多次进行，由于其他提交事务所做的修改和删除，每次返回不同的结果集，此时发生不可重复读 幻读是指在同一查询事务中多次进行，由于其他提交的事务所做的插入操作，每次返回不同的结果集，此时发生幻读表面上看，区别就在于不可重复读能看见其他事务提交的修改和删除，而幻读能看见其他事务提交的插入 1.default：(默认) 默认隔离级别，使用数据库默认的事务隔离级别 2.read_uncommitted:(读未提交) 这是事务最低的隔离级别,他允许另外一个事务可以看到这个事务未提交的数据,这种隔离级别会产生脏读

1、什么是分布式事务 分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务； 2、分布式事务产生的原因 2.1、数据库分库分表 在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表； 分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务； 2.2、业务服务化 业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统； 比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布； 一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性； 3、分布式事务原理简介 数据库本地事务（ACID） 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)，一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行

世上本没有坑，挖的人多了，自然就有坑了。 公司最近要搭一个分布式集群来训练数据，作为一个无知而又热爱求知的小白，自然被虐得头发都掉了一地。 花了整整2.5个星期后，终于在开源哥们的指导下才大概估计到原因所在，最后才在华为的一个技术贴上找到答案，那时候真是Duang的一声，看着进程终于跑起来的那一刻，真的是想来个夕阳下的奔跑来庆祝一下。这过程真的不容易啊，期间基本把google和百度的资料不管相关和不相关都翻了个遍，也没有很好解决问题，那时候心态是真的爆炸了，最后改了一下关键字，才在谷歌结果的最后一页看到华为的帖子有那么几个字相关，没想到点开后就打开了新世界，激动!!!!! 扯淡到此为止，现在来介绍一下部署细节。 本部署是基于ubuntu 16.04 + hadoop + spark + tensorflowOnSpark + tensorflow 1.8 这里集群的环境是1个ps和2个worker hadoop和spark的部署这里不做叙述，网上的资料一大堆，按照来基本上没有问题，有问题的话再找一个其它靠谱的再配，反正最终能运行就可以了。 这里是采取yarn作为资源管理器，具体安装过程可以参考 官网 。网上很多文章都说官方说明文档简略，但是其实踩完坑后发觉，其实真的就这么简略，跑不起来，大多是和自身集群的配置有关。所以这些坑得自己填，官方也只能给提示。 一句话，

微服务架构是一种软件架构风格，将一个复杂的应用拆分为多个服务模块，每个模块负责单一的业务功能对外服务，并且可以单独编译部署。每个模块单独部署，模块之间无法直接通信，所以需要借助RPC（远程过程通信协议）或者通过HTTP协议让模块之间进行通信。dubbo 是一套微服务系统的协调者。运用dubbo时将dubbo的jar引入项目中然后项目初始化的时候就会将当前系统需要发布的服务以及当前系统的IP和端口号发送给注册中心；以及描述当前系统所需要的服务，然后向注册中心请求这些服务所在的IP和端口号。 分布式： 将以一个业务拆分为多个子业务，部署在不同的服务器上。分布式和微服务是一样的。 集群： 分布式是以缩短单个任务的执行时间来提升效率，集群是通过单位时间内执行的效率来提高效率的，集群的每台服务器上部署的是同样的服务，他是有组织性的，一台服务器崩了，其他服务器可以顶上来。而分布式的每个节点都完成不同的功能，如果一个节点崩了则此服务器的服务无法访问，所以最好就是分布式+集群部署。 负载均衡： 负载均衡其实就是集群的前置。集群部署完后，需要一台服务器充当调度者角色，用户的所有请求首先被此调度者服务器接收，然后根据每台服务器的负载情况分发请求。 <HTTP重定向实现负载均衡> 当用户请求某个服务时，请求首先被调度者服务器截获，然后根据某种策略选择集群中的一台服务器

目录： 一、什么是分布式系统？ 二、为什么要走分布式系统架构？ 三、系统如何进行拆分？ 四、分布式之后带来的技术挑战？ 一、什么是分布式系统？ 在谈分布式系统架构前，我们先来看看，什么是分布式系统？ 假设原来我们有一个系统，代码量30多万行。现在拆分成20个小系统，每个小系统1万多行代码。 原本代码之间都是直接基于Spring框架走JVM内存调用，现在拆开来，将20个小系统部署在不同的机器上，然后基于分布式服务框架（比如dubbo）搞一个rpc调用，接口与接口之间通过网络通信来进行请求和响应。 所以分布式系统很重要的特点就是服务间要跨网络进行调用，我们来看下面的图： 此外，分布式系统可以大概可以分成两类。 1. 底层的分布式系统。 比如hadoop hdfs（分布式存储系统）、spark（分布式计算系统）、storm（分布式流式计算系统）、elasticsearch（分布式搜索系统）、kafka（分布式发布订阅消息系统）等。 2. 分布式业务系统 分布式业务系统，把原来用java开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。 举个例子，假设原来你做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1台机器部署。 现在如果你把他这个系统给拆开，权限系统，员工系统，请假系统

Hystrix是什么？ hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。 在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。 Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 为什么需要Hystrix? 在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，如下图: 在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等。 如下图：QPS为50的依赖 I 出现不可用，但是其他依赖仍然可用。 当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图: 在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败 。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险 例如:一个依赖 30个 SOA服务的系统,每个服务 99.99 % 可用

提前先祝大家春节快乐！好了，先简单聊聊。 我从事的是大数据开发相关的工作，主要负责的是大数据计算这块的内容。最近Hive集群跑任务总是会出现Thrift连接HS2相关问题，研究了解了下内部原理，突然来了兴趣，就想着自己也实现一个RPC框架，这样可以让自己在设计与实现RPC框架过程中，也能从中了解和解决一些问题，进而让自己能够更好的发展（哈哈，会不会说我有些剑走偏锋？不去解决问题，居然研究RPC。别急，这类问题已经解决了，后续我也会发文章详述的）。 原理图上我已经标出来流程序号，我们来走一遍： ① Client以本地调用的方式调用服务 ② Client Stub接收到调用后，把服务调用相关信息组装成需要网络传输的消息体，并找到服务地址（host:port），对消息进行 编码 后交给Connector进行发送 ③ Connector通过网络通道发送消息给Acceptor ④ Acceptor接收到消息后交给Server Stub ⑤ Server Stub对消息进行 解码 ，并根据解码的结果通过 反射 调用本地服务 ⑥ Server执行本地服务并返回结果给Server Stub ⑦ Server Stub对返回结果组装打包并 编码 后交给Acceptor进行发送 ⑧ Acceptor通过网络通道发送消息给Connector ⑨ Connector接收到消息后交给Client Stub