1 天前 / 四猿外
又是这个封面，最近这个封面出现的比较频繁，别问为什么？问就是，这个封面 = 内容牛 B 这篇文章我们继续聊分布式相关的内容。 提到分布式系统，就一定绕不开“一致性”，这次我们说说：最终一致性。 最终一致性是现在大部分高可用的分布式系统的核心思路。 估计有人对最终一致性不太熟，先来个简单介绍： 最终一致性指的是系统中的所有分散在不同节点的数据，经过一定时间后，最终能够达到符合业务定义的一致的状态。
1 天前 / Yourtion
全文约 4077 字，预计阅读时间为 12 分钟最近想给项目添加一个简单的分布式请求跟踪功能，从前端发起请求到网关，再从网关调用 SpringCloud 的微服务，这些过程中希望能从日志中看到一个分布式 ID 的链路，通过请求的 ID 可以追踪整一条链路，方便问题的排查。 现成的方案自然是使用 SkyWalking 、 Spring Cloud Sleuth 、Zipkin 之类的组件，但是想到主要的目的记录一个可以一直贯通各个服务的 ID，方便日志查询，也就不想引入太多复杂的组件，最终决定通过 MDC 在日志中输出追踪的 ID，然后在 Feign 和 RestTemplate 中将请求 ID 在微服务中传递。
6 天前 / xF0rk
什么是文件系统？ 文件系统是计算机中一个非常重要的组件，为存储设备提供一致的访问和管理方式。在不同的操作系统中，文件系统会有一些差别，但也有一些共性几十年都没怎么变化： 数据是以文件的形式存在，提供 Open、Read、Write、Seek、Close 等 API 进行访问； 文件以树形目录进行组织，提供原子的重命名（Rename）操作改变文件或者目录的位置。 文件系统提供的访问和管理方法支撑了绝大部分的计算机应用，Unix 的“万物皆文件”的理念更是凸显了它的重要地位。
6 天前 / u578576
阅读大概需要 3 分钟 附源码 [toc] 前言单体架构的服务的日子已经一去不复返了。 当前系统业务和数据存储的复杂度都在提升，分布式系统是目前使用非常普遍的解决方案。 全局唯一 ID 几乎是所有设计系统时都会遇到的，全局唯一 ID 在存储和检索中有至关重要的作用。 ID 生成器在应用程序中，经常需要全局唯一的 ID 作为数据库主键。如何生成全局唯一 ID？ 首先，需要确定全局唯一 ID 是整型还是字符串？如果是字符串，那么现有的 UUID 就完全满足需求，不需要额外的工作。缺点是字符串作为 ID 占用空间大，索引效率比整型低。
7 天前 / 秦夏
这是《漫谈分布式系统》系列的第 24 篇，预计会写 30 多篇。扫描文末二维码，关注公众号，听我娓娓道来。也欢迎转发朋友圈分享给更多人。 扩展性需求带来的架构演进 系列开篇的时候，我就提过，这个系列虽然叫《漫谈分布式系统》，但我会以大数据为核心场景去展开。 所以，之前谈到为了解决「存不下」和「算的慢」的问题，引出了 Hadoop。 但是，实际上分布式系统不只有大数据这个场景，而 Hadoop 也不是唯一的解法。 我们把视线拉回去。起初在单机下，一切都不是问题。逐渐的，当数据量和计算量变大后，就需要在架构上扩容。
9 天前 / HughNian
缘起提到分词一直都是一个比较底层的技术，说简单点就是一个分词系统，说复杂的话它也是属于人工智能范畴，确切说是属于 NLP 自然语言处理范畴。npw 是一个用 Golang 开发的中文分词系统，里面也用到了 NLP 的隐马尔可夫模型，维特比算法等，并没有对词汇进行学习处理。我们只是 NLP 的应用，真正的人工智能 NLP 需要模型训练，需要不停的对不同模型的加解码，得出最优解，这就很深了，npw 不属于这个范畴 (￣▽￣)”。
10 天前 / Yourtion
- 起源 - TCC 概念由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出， 在该论文中，TCC 还是以 Tentative-Confirmation-Cancellation 命名。正式以 Try-Confirm-Cancel 作为名称的是 Atomikos 公司，并且还注册了 TCC 商标。国内最早可查引进 TCC 概念，应是阿里程立 2008 年在 软件开发 2.0 大会 上分享主题《大规模 SOA 系统中的分布事务处理》中。
13 天前 / farliu
分布式一致性协议 - EPaxosDec 21, 2020 | 算法理论| 阅读 | 3.1k 字 | 12 分钟 条评论总结 epaxos 作为 paxos 族中的一员，并不是单独存在的。所以我在文中开篇给出总结，罗列与 basic-paxos、mutli-paxos 之间的区别。带着目的学习，可能相对容易理解一些。 回顾 paxos 的局限性，总结来说存在三个问题： basic-paxos，多个 proposal 提出时，容易形成活锁，影响整个算法的活性。mutli-paxos，通过只允许 leader 提出 proposal，解决活锁问题...
18 天前 / kafeidou
阿里妹导读：12 月 3 日，由阿里云 CIO 学院主办的【2020 中国企业数字创新峰会】在杭州举行。400 位企业 CEO、CTO、CIO 齐聚一堂，共同探讨企业数字化转型经验。阿里巴巴集团副总裁、达摩院数据库首席科学家李飞飞发表了题为《云原生分布式数据库系统——挑战与机遇》的演讲，探讨云原生数据库的价值和商业应用。 文末福利：《阿里云数据库客户案例集》开放下载。 一 背景与趋势 云计算加速数据库系统演进 首先我们看一下云计算的发展给数据库系统带来了哪些变化？数据库系统是计算机领域三大基础软件系统之一，操作系统、编译系统、数据库系统。
19 天前 / 四猿外
这次和大家讲讲分布式事务的 BASE 理论，保证通俗易懂。为了阅读顺畅，开始之前先请大家记住几个名词： BASE——Basically Available（基本可用），Soft state（软状态），Eventually consistent（最终一致性） 2PC——两阶段提交 不用懂，先记住就好了。你负责记住，我负责让你懂。 正文开始： 深夜，我嗒嗒嗒的敲着键盘，我在屏幕上敲下了这么一段话： “2008 年 Dan Pritchett 提出一个与两阶段提交截然不同的分布式事务理论： BASE（Basically Available，Soft state，Eventually consistent）理论。
24 天前 / leehavin
分布式任务调度系统，纯 NET 打造的重量级大数据实时计算平台，万亿级调度经验积累！面向中小企业大数据分析场景。 开源地址：https://github.com/NewLifeX/AntJob 使用教程：https://www.yuque.com/smartstone/blood/antjob 体验地址：http://ant.newlifex.com 功能特点 AntJob 的核心是蚂蚁算法：把任意大数据拆分成为小块，采用蚂蚁搬家策略计算每一块！ （蚂蚁搬家，一个馒头掉在地上，众多小蚂蚁会把馒头掰成小块小块往家里般！） 该算法设计于 2008 年...
26 天前 / 四猿外
引言 CAP 理论，相信很多人都听过，它是指： 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 为什么要理解 CAP 理论？我能说出很多理由来。如果是在职场上，也许最合适的理由是，当领导给出的任务不靠谱时，我们可以依据 CAP 去否决它。 比如，有这么一个任务，给你定了三大目标： 既要提升系统的可用性又要保证数据的实时可见还有提升系统的容错能力看到“既要、又要、还要”，是不是想到了阿里…… OK，如果你深刻理解了 CAP，你会发现完成这个任务是不可能的。
28 天前 / 开发者头条
大家好，我是周刊菌。 以下内容选自「码农周刊 VIP 会员」圈子，每日更新，精彩不断。「码农周刊 VIP 会员」推出 35 周啦！感谢亲们的大力支持！第 035 期「码农周刊 VIP 会员专属邮件周报」已发送完毕，请注意查收。告诉大家一个好消息：已有数位上市公司 CTO 低调订阅了我们的「码农周刊 VIP 会员专属邮件周报」，感谢肯定！ 「码农周刊 VIP 会员」是什么？简介版码农周刊 VIP 会员 = 全年 52 期「VIP 会员专属邮件周报」 + 只限 VIP 会员加入的交流圈子 + 大厂「内推机会」 + N 多福利 详细版 点击「阅读原文」即可查看详细介绍 加入「码农周刊 VIP 会员...
32 天前 / 小咚呱哇子
笔者期望通过一篇权威靠谱、清晰易懂的系统性文章，帮助读者深入理解 Raft 算法，并能付诸于工程实践中，同时解读不易理解或容易误解的关键点。 本文是 Raft 实战系列理论内容的整合篇，我们结合 Raft 论文讲解 Raft 算法思路，并遵循 Raft 的模块化思想对难理解及容易误解的内容抽丝剥茧。算法方面讲解：选主机制、基于日志实现状态机机制、安全正确维护状态机机制；工程实现方面讲解：集群成员变更防脑裂策略、解决数据膨胀及快速恢复状态机策略、线性一致读性能优化策略等。 注：本篇内容较多，建议在大屏 PC 或平板阅读，效果更佳。
36 天前 / 多颗糖
▲点击上方"多颗糖"关注公众号 前文《理解 Paxos》只包含伪代码，帮助了理解但又不够爽，既然现在都讲究Talk is cheap. Show me the code.这次就把文章中的伪代码用 Go 语言实现出来，希望能帮助各位朋友更直观的感受 Paxos 论文中的细节。 但我们需要对算法做一些简化，有多简单呢？我们不持久化存储任何变量，并且用chan直接代替 RPC 调用。 代码地址：https://github.com/tangwz/paxos/tree/naive 记得切换到 naive 分支。 定义相关结构体我们定义 Proposer 如下： type proposer struct { // server id id int // the largest round numbe...