2 天前 / 知了一笑
一、服务间隔离 1、分布式结构分布式系统架构的明显特点，就是按照业务系统的功能，拆分成各种服务，每个服务下面都有自己独立的数据库，以此降低业务间的耦合度，隔离不同的数据库保证系统最大的稳定性等。 例如上图是电商系统中经典的业务场景，订单 - 仓储 - 物流的服务模式，不同服务提供不同的应用场景，服务间存在通信机制，以此实现服务的高可用。 2、隔离思想分布式的架构体系中，涉及一个根本思想逻辑：隔离； 服务和数据库根据业务拆分，进而隔离开来，整个架构中某个服务挂掉，不会影响其他的服务继续执行。
16 天前 / u567995
PowerJob（原OhMyScheduler）是全新一代分布式调度与计算框架，能让您轻松完成作业的调度与繁杂任务的分布式计算。 简介主要特性使用简单：提供前端Web界面，允许开发者可视化地完成调度任务的管理（增、删、改、查）、任务运行状态监控和运行日志查看等功能。定时策略完善：支持CRON表达式、固定频率、固定延迟和API四种定时调度策略。执行模式丰富：支持单机、广播、Map、MapReduce四种执行模式，其中Map/MapReduce处理器能使开发者寥寥数行代码便获得集群分布式计算的能力。
20 天前 / 秦夏
这是《漫谈分布式系统》系列的第 17 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 IO 的重灾区 Shuffle 上一篇，我们讲了大量 IO 导致了 MapReduce 性能不佳。然后引出了基于内存的分布式计算框架 Spark 和 基于内存的分布式存储中间件 Alluxio，来减少 IO。 这两个框架确实很大程度上减轻了 IO 压力，提升了性能。但上篇介绍的重点都比较粗粒度，我们可以进一步深入到执行过程中去，看看还有没有优化的可能。
22 天前 / 虞大胆
本文选自“字节跳动基础架构实践”系列文章。 “字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。 字节跳动存在海量结构化与半结构化数据的诸多存储需求。本文将对字节跳动分布式表格存储系统的演进进行深入剖析，展示我们如何从解决业务需求开始一步一个脚印的朝着业界顶尖的目标靠近。 概要分布式表格存储系统在业界拥有广泛的应用场景。
24 天前 / 秦夏
这是《漫谈分布式系统》系列的第 16 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 MapReduce 的性能问题 上一篇，我们提到，分布式系统中，经常存在中心化的角色，随着集群规模的扩大，这些中心化的角色会达到性能瓶颈，使得系统不能持续横向扩展下去。 然后，我们通过 Federation 等方法解决了这些中心化的 master 的性能问题。
26 天前 / 猿天地
Cat 是什么？CAT（Central Application Tracking）是基于 Java 开发的实时应用监控平台，包括实时应用监控，业务监控。 CAT 作为服务端项目基础组件，提供了 Java, C/C++, Node.js, Python, Go 等多语言客户端，已经在美团点评的基础架构中间件框架（MVC 框架，RPC 框架，数据库框架，缓存框架等，消息队列，配置系统等）深度集成，为美团点评各业务线提供系统丰富的性能指标、健康状况、实时告警等。
29 天前 / 张昊
下载 APP【开源】分布式 ID 生成器耗子 2015 关注赞赏支持【开源】分布式 ID 生成器分布式 ID 生成器背景伴随互联网的发展，无论分布式系统、还是存储都变得更复杂、数据量更大，这些都需要唯一的标识记录。简单举例，数据库单表时，通常使用数据库自带的自增 ID 就可以了，但分库分表后，数据库自带的自增 ID 就无法满足需求了，我们需要有一个算法或服务来生产分布式 ID。 很多公司都会自研唯一 ID 生成服务，来满足唯一标识的问题。
33 天前 / 秦夏
这是《漫谈分布式系统》系列的第 15 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 系列第一章我们讲过，分布式系统把数据的存储和计算切分到多个节点，获得了横向扩展性。 横向扩展的威力无穷，理论上有多少节点，就能汇聚多少存储和计算能力。 从这个角度看，分布式系统有发展成去中心化系统（Decentralized System）的可能。但由于架构设计上的问题，却导致了至少在大数据领域，分布式系统大都不是去中心化系统，反倒都有「中心」。
40 天前 / 秦夏
这是《漫谈分布式系统》系列的第 14 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 数据一致性小结 从系列第 8 篇开始引出高可用性和数据副本，接着深入数据一致性问题，这个章节，已经写了 6 篇了。 这块内容涉及的概念、理论都很多，也是分布式系统面临的核心挑战之一。所以，这里有必要先小结下。 首先，为了达到高可用性，唯一的办法就是数据复制（data replication）。当然，数据副本也能带来性能上的提升等其他好处。
40 天前 / reesunhuang
阿里妹导读：分布式事务中涉及的参与者分布在异步网络中，参与者通过网络通信来达到分布式一致性，网络通信不可避免出现失败、超时的情况，因此分布式事务的实现比本地事务面临更多的困难。本文归纳总结五种分布式事务解决方案，并剖析其特点。较长，同学们可收藏后再看。 文末福利：Java 程序员学习清单。 概述 事务是一组不可分组的操作集合，这些操作要么都成功执行，要么都取消执行。最典型的需要事务的场景是银行账户间的转账：假如 A 账户要给 B 账户转账 100 元，那么 A 账户要扣减 100 元，B 账户要增加 100 元...
41 天前 / u128287
导语 本文针对业务中异常场景处理问题，介绍了基于分布式调度机制的通用重试方案，该方案保证了业务的最终一致性，且大大降低了人工恢复异常数据的成本。 背景 在分布式环境下，我们大部分的系统都不是单独存在的，系统与系统之间的相互依赖已是常态。 从宏观角度看，分布式“依赖”即增加了系统的整体复杂度，也增加了系统出现问题的概率。例如：在做下单操作时，调用支付系统成功，但是最终添加商品超时；当业务系统依赖的下游服务出现严重的系统问题时，导致在一段时间内的业务受到影响。系统问题最终都会体现到数据一致性上。
44 天前 / aoho求索
彻底搞懂 etcd 系列文章（一）：初识 etcd0 专辑概述 etcd 是云原生架构中重要的基础组件，由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册于发现，还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口、实现原理、源码分析，以及实现中的踩坑经验等几方面具体展开介绍 etcd。预计会有 20 篇左右的文章，笔者将会每周持续更新，欢迎关注。 1 etcd 介绍 etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值 (key-value)数据库。
44 天前 / 秦夏
这是《漫谈分布式系统》系列的第 13 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 从 ACID 到 BASE 在业务很简单，数据量不大的时候，传统单机关系数据库就够用了。在各个关系数据库里，很早就实现了单机版的事务，并总结成了 ACID 四个特性。 Atomity，原子性，事务内的所有操作要么全部执行，要么全部不执行。 Consistency，一致性，事务执行完后，数据库仍然保持合法的状态，如不违反主外键约束等。
44 天前 / 大数据技术架构
1 前言 HDFS（Hadoop Distributed File System）是我们熟知的 Hadoop 分布式文件系统，是一个高容错的系统，能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS 以流式数据访问模式存储超大文件，将数据按块分布式存储到不同机器上，并被设计成适合运行在普通廉价硬件之上。本文根据 Hadoop 官网 HDFS Architecture 这一章节提炼而成，加上笔者自己的理解，希望能够帮助读者快速掌握 HDFS。
48 天前 / 我们都是小白鼠
点击上方“蓝字”关注我们 这是小白鼠的第 3 篇原创文章 写在前面分布式架构出现后，越来越多的分布式系统会面临数据一致性的问题。目前，ZooKeeper 是在解决分布式数据一致性上最成熟稳定且被大规模应用的工业级解决方案。 ZooKeeper 保证 分布式系统数据一致性的核心算法就是 ZAB 协议（ZooKeeper Atomic Broadcast，原子消息广播协议）。 ZAB 协议 ZooKeeper 能够保证数据一致性主要依赖于 ZAB 协议的 消息广播，崩溃恢复和数据同步 三个过程。