MySQL 作为一个多线程的数据库,支持客户端对其的并发查询,并且将其默认的隔离级设置为可重复读。那么在并发的操作中 MySQL 是如何隔离各个事务的呢?它实际上使用的是 MVCC 这种机制来管理并发访问,实现了不同版本之间数据的隔离。
在微服务架构盛行的今天,如何保证分布式事务的一致性是每一个后台开发工程师都可能遇到的问题。
作为一名研发工程师,在我的日常工作中经常涉及到各种分布式系统,例如: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 算法的核心概念,重点在于节点的一致性和领导节点的选举。