分布式开发

1、分布式系统简介： 多个节点： 容错性 可扩展性（性能） 固有分布性 消息传递： 节点具有私有存储 易于开发 可扩展性（功能） 对比：并行计算 完成特定的需求： 消息传递的方法： REST（动作、URL） RPC（序列化传输、远端序列化后调用） 中间件（可以存储消息、一对多、消息队列） 一般消息传递的方法： 对外：REST 模块内部：RPC 模块之间：中间件，REST 分布式架构VS为微服务架构 分布式：指导节点之间如何通信 微服务：鼓励按业务划分模块 微服务架构通过分布式架构来实现 多层架构VS微服务架构 微服务架构具有更多的“服务” 微服务通常需要配合自动化测试，部署，服务发现等 目前我们倾向于微服务架构 2、分布式爬虫架构： 并发版爬虫的架构： 目前的问题： 限流问题 去重问题 数据存储问题（固有分布式） 解决限流问题： 单节点能够承受的流量有限–> 将worker放到不同的节点 每个机器都可以起很多worker，任务不一定分发到本机的worker 解决去重问题： 单节点能承受的去重数据量有限 无法保存之前去重结果 基于Key-Value Store（如Redis）进行分布式去重 每来一个请求都要去连接一次去重服务，容易被卡住，所以需要把去重的工作交给worker，worker卡住 没关系，可以起很多个goroutine的worker 解决存储问题： 存储部分的结构

根据阿里云《分布式文件存储系统技术及实现》整理而成。 1 分布式存储的客观需求 存储容量大 考虑对1PB数据进行排序，输入输出都需要1PB，算上中间临时数据，总共需要3-4PB。考虑多用户使用，则集群需要的总的存储空间大于100PB。 高吞吐量，如1PB数据排序需要在2小时内完成，每秒需要几十GB 数据可靠性，在数据规模增长时，降低数据丢失 服务高可用，99.95%意味着每年每年只有4-5小时不可用 高效运维，将日常硬件处理做成流程化，对监控报警要有完善支持 低成本，保证数据安全，正确服务稳定前提下，降低成本，才是分布式存储的核心竞争力 2 小概率事件对分布式系统挑战 单机系统下很少发生的事件，在大规模分布式系统中就会经常发生。 可能发生的小概率问题有： 1 磁盘错误 单机下运行稳定，集群下可能出现频繁。要考虑如何发现慢节点自动规避，发现机器宕机自动绕过。 2 Raid卡故障 发生在高可用节点上的事件。Raid卡是带有电池的缓存块，写入速度很快，能够在断电时保存数据。利用raid卡先缓存数据，之后再写入磁盘中。 3 网络故障 网络架构是一种树形结构，通过顶层交换机连接下层交换机，交换机下连接多台机器。 当上连交换机节点出错时，一部分主机将与其他主机分离，无法发挥作用。 可以将关键角色分布在不同的交换机下，将数据存储多份，某些机器失效时还可以访问到数据。 4 电源故障

一、亚马逊的架构规定 　　最早实践分布式服务化架构思想的公司应该是亚马逊，它早在 2002 年就颁布了下列架构规定，这应该就是 AWS（Amazon Web Service）出现的基础： 　　1. 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 　　2. 团队间程序模块的信息通信，都要通过这些接口。 　　3. 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链接别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 　　4. 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 　　5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 　　6. 不这样做的人会被炒鱿鱼。 　　前面提到过，分布式系统架构会带来很多问题，譬如： 　　1. 一个线上故障的工单会在不同服务和不同团队中转过来转过去； 　　2. 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都做好配额和限流； 　　3. 监控和查错变得更复杂

Redisson概述 Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。 Redisson底层采用的是Netty 框架。支持Redis 2.8以上版本，支持Java1.6+以上版本。 关于Redisson更多详细介绍，可参考 Redssion概述 Redisson提供的分布式锁 可重入锁

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着币价的一直下跌，有传言说，比特币价格此次崩盘，只是大 BOSS 吴忌寒为加速淘汰老旧矿机而祭出的绝招。 无论这个阴谋论真假与否，在整个区块链行业的凛冽寒冬中，价格的涨跌已经左右了太多的人头脑之中的理智。可是，众人之中，究竟有几个人真正理解了区块链技术的密码学机制与分布式计算？究竟有几个人还会关心区块链在技术上的创新？ 尘归尘，土归土。可能只有巨大的泡沫消散之后，区块链才能通过技术创新显示出真正的影响力。让区块链回归技术与应用的本质，这也是我们一直以来的定位。然而，传播这样的内容和话题，离不开货真价实的技术干货，以及有感染力的人物和故事。 我们今天的内容就来自于这样一个女生： 她是工业与系统工程专业出身，做过顶级投行高盛的分析师，做过著名风投 a16z 的合伙人——这都是许多人梦寐以求的工作。但是，功成名就的路上，她却发现编程才是自己想要的生活。 笨办法学会编程？她没学会。如何用 HTML/CSS 做一个网页？她开始上瘾了。所以，没有选择斯坦福、MIT 的编程学位，她更喜欢 Hack Reactor 的全栈动手实践。先学 JavaScript、React，后面的想法是机器学习、计算机视觉……这个女生就是 Preethi Kasireddy。 接触区块链之后，金融从业背景和全栈编程能力让 Preethi

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性： 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。 例如应用程序需要更新多条相关数据时就需要进行事务处理。 什么是分布式事务? 当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。 分布式事务与 XA 规范 分布式事务是指会涉及到操作多个数据库的事务，同样必须保证 ACID。其就是将对同一库事务的概念扩大到了对多个库的事务：对同一库的 SQL 操作对应了分布式事务中对一个库的事务。 X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA 规范的基础是两阶段提交协议

一 什么是 ZooKeeper ZooKeeper 的由来 下面这段内容摘自《从Paxos到Zookeeper 》第四章第一节的某段内容，推荐大家阅读以下： Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以， 雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。 关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起， 雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。 1.1 ZooKeeper 概览 ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache

作者知乎id：一路走好 本人目前做图的底层存储引擎“分片和副本分布式可扩展”相关的研究，来满足业务的快速增长。 本文内容大量来自被我阅读的文章。感谢王建奎博士~~ 华为 先来说说最神秘的华为吧，华为的图数据库构建在多模数据库中，由高斯实验室负责原型研发，图数据库的 headcount 由任总钦点，图数据库在华为重要性可想而知，但是由于华为保密要求严格，凡事都不让对外说。技术领先，设计方案简单高效。其他朋友不方便多跟我说，不过团队从现在到前后会新增 至少 20 个 headcount，任总有要求，非招人不可大有可为呀。如果有想去上海工作的朋友，欢迎联系我，我帮你联系我的朋友。 费马科技 洪春涛学长在北京BDTC2017中国大数据技术大会上深入分析了当时图数据库和图计算领域的难点、现状以及费马在2个领域的优化和产品能力。我当时真的对那几个优化数字感到震惊费马的性能真的非常好，团队也非常专业。京东金融是他们的一个客户案例（详细可查看：https://fma-ai.cn/case）。 费马科技是一个专注图数据库和图计算的创业公司，主打：快如闪电的高性能图数据存储及分析平台。 LightGraph 是费马科技自主研发的图数据库产品。其主要特点是单机大数据量，高吞吐率，以及灵活的 API，同时支持高效的在线事务处理（OLTP）和在线分析处理（OLAP）。LightGraph支持 TB

初始需求 元数据的存储（小数据） 分布式、高可用 读多写少、高性能读 有序访问 设计 单机层面 节点数据结构的选取 树结构，每个节点是一个ZNode 数据保存在内存中 优点：高效读写 为什么ZK不擅长存储大的数据？ 单机高效写磁盘 高效写磁盘的两种方式： 顺序写磁盘 预分配磁盘空间 ZK每次写磁盘，先申请固定大小的磁盘空间，之后再写磁盘，大大提升写入性能。 顺序写数据 每次写入操作，ZooKeeper会附加一个数字标签，表明ZooKeeper中的事务顺序 高可用、宕机可恢复 快照+事务日志 什么时候记录事务日志？ 如何快照？新起线程，不影响主流程 分布式层面 顺序写数据 一主多从结构，只有一台master服务器对外提供写服务，每次写记录ZXID事务Id。原子写，保证mei yo 如何保证数据强一致 写的策略，半数以上机器写成功后返回。 写数据流程，非Leader节点会把请求转发给leader，写成功后leader再通知该节点。 ZAB协议：初始阶段/宕机恢复（原子广播） 如何提高读的性能 follower节点，observer节点都可以对外提供读数据能力 怎么保证读取的强一致？ 客户端在调用前，可以先申请连接的主机同步leader数据，调用sync()方法 。 水平扩容 ZK做的不好的地方。 ZooKeeper 在水平扩容扩容方面做得并不十分完美，需要进行整个集群的重启

简介 消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。当下主流的消息中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。其能在不同平台之间进行通信，常用来屏蔽各种平台协议之间的特性，实现应用程序之间的协同。其优点在于能够在客户端和服务器之间进行同步和异步的连接，并且在任何时刻都可以将消息进行传送和转发。是分布式系统中非常重要的组件，主要用来解决应用耦合、异步通信、流量削峰等问题 消息中间件的作用 消息中间件几大主要作用如下: 解耦 降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 冗余(存储) 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕