3 天前 / HueiFeng
前言 最近，工作中要为现在的老系统做拆分和升级，刚好遇到了分布式事务、幂等控制、异步消息乱序和补偿方案等问题，刚好基于实践结合个人的看法记录一下一些方案和思路。 分布式事务 首先，做系统拆分的时候几乎都会遇到分布式事务的问题，一个仿真的案例如下： 项目初期，由于用户体量不大，订单模块和钱包模块共库共应用（大war包时代），模块调用可以简化为本地事务操作，这样做只要不是程序本身的BUG，基本可以避免数据不一致。
24 天前 / 公众号_coredump
好久没更新了，这篇文章，我是来扯淡的。回忆一下过去。 零想起当年刚开始实习的时候，我的第一个任务就是——写一个抽奖程序。虽然业务需求很简单，但是老大给我提了一些问题，让我深深地学习、思考了一番： 怎么保证安全？千万不要一个奖品被两个人抽到了。怎么保证性能不要太差？很多人同时抽，怎么减少冲突？等等。经过这个简单程序的锤炼，当时的我对数据库 [1]、事务 [2]、隔离级别 [3]开始有了比较深的了解，而不再仅仅停留在课本上。从那个时候开始，我就觉得，数据库真是个神奇的东西，特别是 SQL 和事务。
29 天前 / 陆道峰-MLSys
下一代 AI 应用需要不断和环境进行交互，并且在交互中学习。这些应用暴露了新的系统需求：性能和弹性。本文提出了 Ray 解决上述问题。 Ray 实现了动态执行引擎，可以表达任务并行和 actor 模型计算任务。它通过分布式调度器以及分布式容错存储来实现高性能与容错。 问题与方案 AI 中的监督学习部分，已经出现了优秀的深度学习框架，使用定制的硬件加速计算。但是对于新兴的 AI 应用不仅要收集探索数据，还要采取动作不断和环境交互学习，这一类可以概括为强化学习。
33 天前 / 陆道峰-MLSys
简介 Mesos 是一个在多个集群计算框架中共享集群资源的管理系统，它提高了集群资源利用率，避免了每个计算框架数据复制。 通过分布式两层调度模型实现了细粒度的资源分配：由 Mesos 决定为每个框架提供多少资源，框架决定接受哪些资源，以及把计算任务分配到哪里去执行。 问题与方案 2010 年代计算框架百花齐放，相继出现 MapReduce[1]、MPI、Dryad、Pregel 等。很明显，新的集群计算框架还会不断涌现，不存在满足所有应用需求的集群计算框架，因此企业、研究机构会在同一个集群中运行多个计算框架。
38 天前 / u539609
今年 (2020)7 月初，Volcano 发布了 1.0 版本。1.0 做为里程碑版本，在 Volcano 整个规划中起到了承上启下的作用。 此次发布的 1.0 版本支持了 GPU 共享，作业动态扩缩容，批任务抢占等功能，并主要加强了稳定性；同时，在 1.0 发布后 Volcano 也在线下讨论了分布式调度系统的未来发展趋势等。 作者 | 华为云原生团队 分布式调度系统的历史 在分析趋势之前，我们先看一下分布式调度系统的历史。
38 天前 / 知了一笑
一、Cassandra 简介 1、基础描述 Cassandra 是一套开源分布式 NoSQL 数据库系统。它最初由 Facebook 开发，用于储存收件箱等简单格式数据，此后，由于 Cassandra 良好的可扩展性，逐渐发展成为了一种流行的分布式结构化数据存储方案。 2、特点分析弹性可扩展性 Cassandra 是高度可扩展的；它允许添加更多的硬件以适应更多的客户和更多的数据根据要求，可以根据业务的数据流量轻松扩展集群规模。 架构特点 Cassandra 可以基于分布式运行，并采用了许多容错机制。由于去中心化无主的策略，所以没有单点故障。可以做到不停服滚动升级。
38 天前 / 秦夏
这是《漫谈分布式系统》系列的第 21 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 贴近性能优化的本质 上一篇文章，简单介绍了基于规则的优化 RBO，最后提到 RBO 由于是从经验归纳而来的，所以无法解决很多问题。 根本原因在于经验归纳这个方法是有缺陷的，很难面面俱到。 比如查询走索引的例子，如果 value 分布非常不均衡，那走索引反倒不如全表扫描。 再比如多表 join 的情况，哪个表放前面更好，显然是无法总结出固定规则的。
47 天前 / BloomingRose
点击上方蓝字 关注我们 每一个程序员架构梦的实现之路上，总是绕不开分布式系统 CAP 这个理论的学习。如果你还没有了解过，可以翻看之前的文章，相信我，如果你想成为架构师，这个理论无论是在工作中还是面试中吹水，你始终都是需要的 程序员修神之路 -- 晦涩难懂的 CAP，是否完全正确？ CAP 理论作为分布式的重要理论基础，指出了在分布式环境下，其实只有 AP 和 CP 两种模型去选择。BASE 理论作为 CAP 理论的一个延伸，主张牺牲一致性去换取可用性。反之，一个分布式系统也可以去牺牲可用性去换取一致性。
48 天前 / 阿斯兰
3 分布式系统抽象 讨论编程语言时，我们使用通用术语并用函数、运算符、类、变量和指针来定义我们的程序。通用的词汇可以帮助我们避免每次都为了描述某些东西而发明新词。我们的定义越精确、越没有歧异，听众也就越容易理解。 在开始学习算法之前，我们首先要了解分布式系统中的词汇：这些定义你会经常在演讲、书籍和论文中遇到。 链路 网络是不可靠的：消息会丢失、延迟或被打乱。记住这一点之后，我们来尝试构建几种通信协议。我们从最不可靠的协议开始，确定它们可能处于的状态，然后找出可以为协议增加的东西使它提供更好的保证。
48 天前 / rfyiamcool
shark？对的，shark 是我们项目名，为什么叫鲨鱼？ 同事们的项目好多都是海产品，比如 starfish ？ 那么我的任务系统理所当然也是一个海产品了。 shark 可以做很多东西，可以把他理解为一个简单版的 ansible 和 saltstack，架构设计上更趋于 salstack。起初单纯要做 kubernetes 集群部署工具，但随着后面的需求越来越多，所以抽象为面向于服务和主机的任务系统。相比 ansible 和 satlstack 来说，更好的分布式设计，对多机房友好、grpc 接口更友好、扩展功能更适配我们自己。
55 天前 / sjf0115
阿里妹导读：分布式一致性（Consensus）作为分布式系统的基石，一直都是计算机系统领域的热点。近年来随着分布式系统的规模越来越大，对可用性和一致性的要求越来越高，分布式一致性的应用也越来越广泛。纵观分布式一致性在工业界的应用，从最开始的鼻祖 Paxos 的一统天下，到横空出世的 Raft 的流行，再到如今 Leaderless 的 EPaxos 开始备受关注，背后的技术是如何演进的？本文将从技术角度探讨分布式一致性在工业界的应用，并从可理解性、可用性、效率和适用场景等几个角度进行对比分析。 文末福利：《分布式文件存储系统技术及实现》技术公开课。
59 天前 / 猿天地
目录阐述背景 Leaf snowflake 模式介绍 Leaf segment 模式介绍 Leaf 改造支持 RPC 阐述背景不吹嘘，不夸张，项目中用到 ID 生成的场景确实挺多。比如业务要做幂等的时候，如果没有合适的业务字段去做唯一标识，那就需要单独生成一个唯一的标识，这个场景相信大家不陌生。 很多时候为了图方便可能就是写一个简单的 ID 生成工具类，直接开用。做的好点的可能单独出一个 Jar 包让其他项目依赖，做的不好的很有可能就是 Copy 了 N 份一样的代码。 单独搞一个独立的 ID 生成服务非常有必要，当然我们也没必要自己做造轮子，有现成开源的直接用就是了。
69 天前 / 秦夏
这是《漫谈分布式系统》系列的第 20 篇，预计会写 30 篇左右。每篇文末有为懒人准备的 TL;DR，还有给勤奋者的关联阅读。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 细节是负担，甩掉有代价 前面几篇文章，我们讲到，MapReduce 和 Spark 在引入 SQL 之后，诞生了 Hive 和 Spark SQL，大大提升了开发性能。 然后又讲到，受 Shuffle 性能优化的启发，对 SQL Join 的性能做了一些优化。 在讲 Join 性能优化的时候，虽然我没明说，但也能隐约感觉到一个不好的趋势。
69 天前 / CainGao0
前面几篇文章提到了微服务相关系统的使用与搭建，在微服务架构下的问题也比较突出。正常系统下我们的每个请求都会在同一个系统中进行输出。但是在微服务架构中一个请求可能设置一到多个服务进行处理。服务之间相互依赖，服务之间形成一个调用链。如果调用链之间的某个服务出现故障那么整个调用链都将会受到影响。 为什么需要链路追踪架构设计之初就提出了需要进行分布式链路追踪系统，而且当时也对需求进行了大概的一个推演。我们希望能够得到的是一个下图这样的结构。每次请求能够获取到该请求的调用链。
69 天前 / yes的练级攻略
大家好，我是 yes。 今天来说说限流的相关内容，包括常见的限流算法、单机限流场景、分布式限流场景以及一些常见限流组件。 当然在介绍限流算法和具体场景之前我们先得明确什么是限流，为什么要限流？。 任何技术都要搞清它的来源，技术的产生来自痛点，明确痛点我们才能抓住关键对症下药。 限流是什么？首先来解释下什么是限流？ 在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。