最新 | 最热门 | 最高评价

+0  TiDB 在 Raft 成员变更上踩的坑

Tag: distributed | raft | paxos | consensus | membership | tidb
张炎泼(xp) 发于 2021年01月05日 08:00 | 点击: 81 | 展开摘要
问题

上次跟好基 黄东旭 在咖啡厅撩天的时候谈笑风生地探讨了一个 TiDB 使用 Raft 时遇到的问题:

TiKV 层的 Raft 实现, 使用的是 Raft 单步变更 算法(每次添加或删除一个节点),
例如副本由 abc 变成 bcd 过程中,
先加入 d, 变成 abcd , 再去掉 a 变成最终配置 bcd.

这中间经历的4节点的状态 abcd, 有可能在出现二分的网络割裂(ad | bc)时导致整个集群无法选出leader.
这种网络割裂在跨机房部署时容易出现

查看全文: http://www.udpwork.com/item/17475.html

+0  200行代码实现基于paxos的kv存储

Tag: algo | distributed | replication | paxos | kv | 分布式 | 存储
张炎泼(xp) 发于 2020年10月28日 08:00 | 点击: 85 | 展开摘要
前言

写完 paxos的直观解释 之后,
网友都说疗效甚好, 但是也会对这篇教程中一些环节提出疑问(有疑问说明真的看懂了

查看全文: http://www.udpwork.com/item/17478.html

+0  后分布式时代: 多数派读写的’少数派’实现

Tag: algo | distributed | quorum | majority | replication | paxos | raft | 分布式 | 多数派
张炎泼(xp) 发于 2020年10月18日 08:00 | 点击: 91 | 展开摘要
前言

paxos可以看做是2次 多数派读写 完成一次强一致读写. 多数派要求半数以上的参与者(paxos中的Acceptor)接受某笔操作. 但 多数派读写 并不一定需要多于半数的参与者, 分布式系统中某些场合的优化, 可以通过减少参与者数量来完成的.

多数派读写:分布式系统的基础

分布式系统中, 其中一个基础的问题是如何在不可靠硬件(低可用性)基础上构建可靠(高可用性)的服务,
要达成这个目标, 核心的手段就是复制(例如一份数据存3个副本).
而复制过程中的一致性

查看全文: http://www.udpwork.com/item/17479.html

+0  可靠分布式系统-paxos的直观解释

Tag: algo | distributed | consensus | fault-tolerant | quorum | replication | paxos | 分布式 | 一致性 | 容错 | 多数派
张炎泼(xp) 发于 2020年06月01日 08:00 | 点击: 83 | 展开摘要
前言

paxos是什么?

在分布式系统中保证多副本数据强一致的算法.

paxos有啥用?

没有paxos的一堆机器, 叫做分布式;

有paxos协同的一堆机器, 叫分布式系统.

Google Chubby的作者Mike Burrows说过:

这个世界上只有一种一致性算法,那就是Paxos …

其他一致性算法, 都可以看做paxos在实现中的变体和扩展.

另外一个经常被提及的分布式算法是raft, raft的贡献在于把一致性算法落地.
因为 Leslie

查看全文: http://www.udpwork.com/item/17480.html

+0  Erasure-Code-擦除码-3-极限篇

Tag: storage | ec | erasure-code | distributed | replication | 擦除码 | 纠删码 | 伽罗瓦 | | 伽罗瓦域 | GF256
张炎泼(xp) 发于 2020年02月07日 08:00 | 点击: 79 | 展开摘要
书接上回

上一篇 第二篇:实现 中, 我们介绍完了基于GF(2⁸)伽罗瓦域的标准实现以及做了正确性分析,
我们也提到:

在EC的计算中, 编解码是一个比较耗时的过程,
因此业界也在不断寻找优化的方法, 不论从理论算法上还是从计算机指令的优化上,
于是下一篇我们将介绍如何把EC实现为一个高效的实现.

本文我们来介绍, 在实际生产环境使用时还需做哪些优化,
来将EC打造成一个高效的实现.

第一篇:原理 再上一篇

查看全文: http://www.udpwork.com/item/17482.html

+0  Erasure-Code-擦除码-2-实现篇

Tag: storage | ec | erasure-code | distributed | replication | 擦除码 | 纠删码 | 伽罗瓦 | | 伽罗瓦域 | GF256
张炎泼(xp) 发于 2020年02月04日 08:00 | 点击: 81 | 展开摘要
书接上回

上一篇 第一篇:原理 中, 我们介绍了EC的基本原理,
实际上EC的存储跟恢复过程可以理解为:
一条k-1次曲线可以通过k个系数或曲线上的点来确定.

我们也提到:

但这套理论还不能直接应用到线上产品中.
因为计算机中还要考虑数字大小限制, 例如k个32位整数作为数据,
通过Vandermonde矩阵生成校验块, 那校验块的数值几乎确定会溢出.

本文我们来解决这个问题, 看如何将EC的理论应用到计算机中, 保证计算不会溢出.

第一篇:原理 上一篇

查看全文: http://www.udpwork.com/item/17483.html

+0  分布式系统中唯一ID的生成

Tag: Distributed System | ID | Service | 分布式
四火 发于 2017年06月30日 23:59 | 点击: 1907 | 展开摘要
其实老早就像写一点这个话题。几乎我见过的所有大型系统中,都需要一个唯一ID的生成逻辑。别看小小的ID,需求和场景还挺多:

这个ID多数为数字,但有时候是数字字母的组合;

可能随机,也可能要求随时间严格递增;

有时ID的长度和组成并不重要,有时候却要求它严格遵循规则,或者考虑可读性而要求长度越短越好;

某些系统要求ID可以预期,某些系统却要求ID随机性强,无法猜测(例如避免爬虫等等原因)。

独立的生成服务

比如数据库。最常见的一种,也是应用最多的一种,就是利用数据库

查看全文: http://www.udpwork.com/item/16335.html

+0  Spark性能优化——和shuffle搏斗

Tag: Distributed System | shuffle | Spark
四火 发于 2016年05月22日 02:48 | 点击: 1571 | 展开摘要
Spark的性能分析和调优很有意思,今天再写一篇。主要话题是shuffle,当然也牵涉一些其他代码上的小把戏。

以前写过一篇文章,比较了几种不同场景的性能优化,包括portal的性能优化,web service的性能优化,还有Spark job的性能优化。Spark的性能优化有一些特殊的地方,比如实时性一般不在考虑范围之内,通常我们用Spark来处理的数据,都是要求异步得到结果的数据;再比如数据量一般都很大,要不然也没有必要在集群上操纵这么一个大家伙,等等。事实上,我们都知

查看全文: http://www.udpwork.com/item/15513.html

+0  Notes: Spark metrics

Tag: Distributed System | metrics | Spark
四火 发于 2016年03月07日 13:25 | 点击: 1786 | 展开摘要
Below are some notes taken for future reference based on the brainstorm meeting last week, with company confidential information removed.

Background

The team use a home made workflow to manage the computation for the cost and profit, and

查看全文: http://www.udpwork.com/item/15309.html

+0  Spark的性能调优

Tag: Distributed System | Recommended | Spark | 性能
四火 发于 2015年12月21日 14:55 | 点击: 1682 | 展开摘要
下面这些关于Spark的性能调优项,有的是来自官方的,有的是来自别的的工程师,有的则是我自己总结的。

基本概念和原则

首先,要搞清楚Spark的几个基本概念和原则,否则系统的性能调优无从谈起:

每一台host上面可以并行N个worker,每一个worker下面可以并行M个executor,task们会被分配到executor上面去执行。Stage指的是一组并行运行的task,stage内部是不能出现shuffle的,因为shuffle的就像篱笆一样阻止了并行task的运

查看全文: http://www.udpwork.com/item/15067.html

+0  Hadoop的Map-side join和Reduce-side join

Tag: Distributed System | Hadoop | Join
四火 发于 2014年07月13日 12:36 | 点击: 3075 | 展开摘要
Hadoop中连接(join)操作很常见,Hadoop“连接”的概念本身,和SQL的“连接”是一致的。SQL的连接,在维基百科中已经说得非常清楚。比如dataset A是关于用户个人信息的,key是用户id,value是用户姓名等等个人信息;dataset B是关于用户交易记录的,key是用户id,value是用户的交易历史等信息。我们当然可以对这两者以共同键用户id为基准来连接两边的数据。

首先,在一切开始之前,先确定真的需要使用Hadoop的连接操作吗?

如果要把两个

查看全文: http://www.udpwork.com/item/12732.html

+0  Hadoop的Secondary Sorting

Tag: Distributed System | Hadoop | MapReduce | Secondary Sorting | 排序
四火 发于 2014年06月04日 23:31 | 点击: 2028 | 展开摘要
这几天项目中使用Hadoop遇到一个问题,对于这样key-value的数据集合:id-biz object,对id进行partition(比如根据某特定的hash算法P),分为a份;使用数量为b的reducer,在reducer里面要使用第三方组件进行批量上传;上传成文件,文件数量为c,但是有两个要求:

上述a、b、c都相等,从而使得每个partition的数据最终都通过同一个reducer上传到同一个文件中去;

每个reducer中上传的数据要求id必须有序。

最开始

查看全文: http://www.udpwork.com/item/12589.html
|<<<12>>>| 一共2页, 23条记录