分布式技术

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

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

分布式一致性问题 在分布式系统中一个需要解决的重要问题就是数据的复制。 分布式系统对于数据的复制需求一般都来自于以下两个原因： 为了 提高系统的可用性 ，以防止单点故障引起的系统不可用 提升系统的整体性能 ，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。 所谓的分布式一致性问题，是指在分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。 简单地讲，数据一致性就是指在对一个副本数据进行更新的同时，必须确保也能够更新其他的副本，否则不同副本之间的数据将不再一致。 可能会有人想到这种解决方案： 将写入的动作阻塞，直到数据复制完成后，才完成写入动作。 这似乎能解决问题，可 当应用场景中有非常多的写请求时，系统的性能将急剧下降。 总的来讲，我们无法找到一种能够满足分布式系统所有系统属性的一致性解决方案。因此如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。 于是就出现了以下一致性级别。 强一致性 这种一致性级别是最符合用户直觉的，它要求 系统写入什么，读出来的也会是什么 ，用户体验好，但 实现起来往往对系统的性能影响极大 。 弱一致性 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能保证到某个时间级别后

提前先祝大家春节快乐！好了，先简单聊聊。 我从事的是大数据开发相关的工作，主要负责的是大数据计算这块的内容。最近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

简介 鸿鹄云Cloud是基于SpringCloud来封装的，是一系列框架的有序集合。利用Spring Boot的开发模式简化了分布式系统基础设施的开发，如 服务发现、注册、配置中心、消息总线、负载均衡、断路器、数据监控 等（这里只简单的列了一部分），都可以用Spring Boot的开发风格做到一键启动和部署。鸿鹄云Cloud将目前比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终整合出一套简单易懂、易部署和易维护的分布式系统架构平台。 鸿鹄Cloud组成 SpringCloud的子项目，大致可分成两类： 一类是对现有成熟框架Spring Boot的封装和抽象，也是数量最多的项目； 第二类是开发了一部分分布式系统的基础设施的实现，如SpringCloud Stream就是kafka, ActiveMQ这样的角色。开发人员进行微服务的实践，第一类子项目就已经足够使用，如： SpringCloud Netflix 是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。 SpringCloud Config 将配置信息中央化保存, 配置SpringCloud Bus可以实现动态修改配置文件。 SpringCloud Bus 分布式消息队列，是对Kafka,

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

分布式设计 1.复制 作用 对数据备份,实现高可用 提高吞吐量,实现高性能 分类 主从架构 性能 一主多从,读写分离,提高吞吐量 可用性 主库单点,一旦挂了,无法写入 从库高可用 一致性 数据同步存在延迟,读时从库中返回的可能是旧数据 解决方案 直接忽略,存在延迟很正常 班不同步复制(semi-sync),主从同步完成写请求才返回,吞吐量降低 选择读主 ˼· 写操作时,根据库+表+业务特征生成key设置到缓存中并设置超时时间(大于等于主从数据同步时间),读操作时,同样方式生成key,先去查缓存,如果命中则读主库,否则读从库 技术难点 主从数据同步时间的计算 不同网络,配置下,时间不一样 很多数据库的中间件就是使用的这种思路,如mycat等,但是中间件的成本同样不低 对于即时性有要求的接口,直接从主数据库读 读写分离的情况下,并发出现更新丢失问题 悲观锁 必须加载主数据库商,这样就不能做读写分离 乐观锁 可以 update当前读,这样也不能做读写分离 有一致性要求的接口,无法读写分离,只能从主库中操作 多主架构(互为备份) 性能 负载均衡 可用性 高可用 一致性 和主从架构一样 主主从从 高性能 高可用 一致性 和主从一样 主备 主库提供读写服务,备库做故障转移用 性能一般 提高性能 设置缓存 高可用 无一致性问题 使用广泛 58和阿里云 mysql主从同步的原理 2.分片/分库分表

本文根据黄炎在2018年7月7日【MySQL技术沙龙 ・ 成都站】现场演讲内容整理而成。 黄炎 爱可生研发总监，深入钻研分布式数据库相关技术，擅长业界相关MySQL中间件产品和开发，以及分布式中间件在企业内部的应用实践。 MySQL中间件性能测试 I 摘要： 我今天代表我的团队向大家来介绍一下MySQL中间件性能的测试，为大家带来一些不太一样的故事，包括我们在做性能测试的时候一些不太一样的视角。 分享大纲： 1.性能测试的常见的(错误)方法 * 3 2.性能测试的一些(我们用的)方法 * 2 3.分布式事务相关 * 1 我今天代表我的团队向大家来介绍一下MySQL中间件性能的测试，之所以讲选这个主题是因为我注意到大家都是高级的DBA，我们也有很多的高级的DBA，跟大家聊天的时候都会注意到，大家对于性能测试的第一印象： 性能 = sysbench 测试 = run 结果 = tps 数值要高大上 性能就是sysbench，然后测试就是跑一下，这就叫性能测试了，结果就是要TPS或者QPS，数值一定要高大上，这是大家对性能测试测试的第一印象也可能是唯一的印象。我们公司是属于乙方的技术服务提供商，我们对业界的很多产品进行过性能测试，所以今天想为大家带来一些不太一样的故事，以及我们在做性能测试的时候一些视角。 我今天大概会向大家介绍三件事情： 第一件事情 是我们观察到，大家在做性能测试的时候

摘　要:针对海量图片给网站带来的访问速度下降、性能压力增大和I/O瓶颈等问题,提出一种海量图片的分布式存储及负载均衡技术。通过把图片数据和 网站内容分开部署、在数据库中记录和维护图片服务器状态信息等方法实现图片和页面数据的分离。实验结果表明,该技术能提高网站的访问速度和运行效率,并可 动态增加图片服务器的数量满足日益增加的性能需求。 　　关键词:海量图片;分布式存储;负载均衡 　　【Abstract】Aiming at the problems of the mass images can cause to Web site such as lower access speed, more performance pressure, I/Operformance bottle-neck, etc., a technology of distributed store and load balance for mass images is proposed. By the means of deploying Website pages and images separately and recording status of image servers in database, solves the problem of separation for image data and

Elasticsearch简介 * Elasticsearch是一个 实时的 分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。 它可以用于 全文搜索， 结构化搜索以及 分析，当然你也可以将这三者进行组合。 Elasticsearch是一个 建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。 Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流。 Elasticsearch的 上手是非常简单的。它附带了很多 非常合理的默认值