论文笔记
樊文飞院士的论文解读(DGFD, GAR)
在微服务架构盛行的今天, 如何保证分布式事务的一致性是每一个后台开发工程师都可能遇到的问题.
作为一名研发工程师, 在我的日常工作中经常涉及到各种分布式系统, 例如: ETCD, Redis, k8s 等. 这些分布式集群在部署的时候我们通常将节点的数量设置为奇数个, 这似乎是一个约定俗成的规则. 但是为什么? 除了偶数节点容易出现投票平票的情况是否还有其他的原因?
中心性算法用于理解图中特定节点的左右及其对网络的影响, 可以帮助我们识别最重要的节点.
在大数据的场景下我们都知道当单表数量达到 2000 万或者 2 GB 的时候就需要进行分库分表. 但是所有数据按照指定的分片键进行分库分表后又会产生一个新的问题: 如何对非分片键进行查询? 当然我们可以迅速想到一个暴力的方法就是使用多线程同时查找所有的分区, 然后再对每个线程的结果进行合并汇总. 但是显然这个方案的效率很低.
我们能否直接从非分片键中判断出这条数据在哪个分区呢? 答案是: 可以的. 本文会介绍其中的一种方法: 基因法.
Kafka 是目前最主流的分布式流式处理平台, 它以高吞吐、可持久化、可水平扩展、支持流式数据处理等多种特性而被广泛使用.
这段时间一直在更新自己的博客, 碰到三个很困扰的问题:
git add
命令执行后总有 Warning 提示: Warning: in the working copy of CRLF will be replaced by LF the next time Git touches it.
git clone
一个新的 repo
会直接显示文件 modified
, 明明什么都没有改动.后来发现这 3 个问题其实都是一个问题导致的: CRLF
符号. 网上搜索有很多人也遇到同样的问题, 都说要更改 Git 的配置, 但是没有人把原理说得很明白, 今天写文档记录一下.
在一个分布式系统中, 通常拥有许多节点. 节点之间如果需要达成共识, 确保节点之间的一致性成为了所有分布式系统都关注的问题.
Raft 是非常经典的一个分布式算法, 它可以保证一个分布式系统中所有节点都保持连续的一致性状态, 是一种用于管理复制日志的一致性算法. Raft 算法旨在通过提供容错和确保选出单个领导者来协调操作所有节点. 本文中我们将深入研究 Raft 算法的核心概念, 重点在于节点的一致性和领导节点的选举.
"一致性 Hash" 似乎是一个具有迷惑性的名字, 因为 Hash 函数的结果不管在哪里计算都应该是一样的, 为什么会存在一致性的问题? 其实我们提出一致性 Hash 这个概念是为了解决分布式存储中的问题. 在分布式存储中不同的机器会存储不同的对象的数据, 我们使用 Hash 函数来建立数据到服务器之间的映射关系. 那么为什么会存在 "不一致" 呢?
我们都知道的是 TCP 连接的建立存在 "三次握手, 四次挥手", 但是这中间到底发生了什么? 为什么挥手的次数要更多? 如果只用两次握手会怎么样? 如果握手和挥手的过程中存在网络延迟或者包的丢失会发生什么? 这篇文章将会给你答案.