摘要: 从执行的结果来看,随着服务器的增加,分片的结果也不一样 当只有一台服务器的时候,所有分片都到这一台服务器上 当服务器增加到两台的时候,分片的结果是0 1 2 3 4和5 6 7 8 9 当服务器增加到三台的时候,分别结果是0 1 2 9和3 4 5和6 7 8 而且,还发现,在一次任务执行过程中,每 阅读全文
posted @ 2018-01-17 11:38 废物大师兄 阅读(974) 评论(0) 推荐(0)
摘要: 阅读全文
posted @ 2018-01-16 15:23 废物大师兄 阅读(6476) 评论(0) 推荐(1)
摘要: 有几张比较重要的图 第1张图,数据保存的差异 第2张图,分支简介 Git 的分支,其实本质上仅仅是指向提交对象的可变指针。Git 的默认分支名字是 master。 在多次提交操作之后,你其实已经有一个指向最后那个提交对象的 master 分支。它会在每次的提交操作中自动向前移动。 创建分支 分支合并 阅读全文
posted @ 2018-01-16 15:16 废物大师兄 阅读(557) 评论(0) 推荐(0)
摘要: 1、版本控制系统 1.1、集中化的版本控制系统 一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新 1.2、分布式的版本控制系统 客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来 2、三种状态 Git 有三种状态 阅读全文
posted @ 2018-01-15 22:18 废物大师兄 阅读(745) 评论(0) 推荐(1)
摘要: 共享内存模型 阅读全文
posted @ 2018-01-11 15:44 废物大师兄 阅读(484) 评论(0) 推荐(0)
摘要: 背景 之前面试的时候被问到关于mq如何保证消息的顺序问题,当时没回答好,网上也没找到满意的答案,于是自己想了一个 问题描述 假设,A和B通过消息队列通信,A发了先后发了2条消息m1和m2。A发出的顺序是m1、m2,结果m2先到达队列,m1后进的,那么在队列中m2在前m1在后,假设这两条消息是有依赖关 阅读全文
posted @ 2018-01-11 13:19 废物大师兄 阅读(9851) 评论(5) 推荐(1)
摘要: Transaction Isolation Levels InnoDB支持SQL1992标准中的四种隔离级别:READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE。默认的隔离级别是REPEATABLE READ。 通过SET TRA 阅读全文
posted @ 2018-01-10 22:26 废物大师兄 阅读(1043) 评论(0) 推荐(1)
摘要: Locking Reads 在同一个事务中,如果你先查询数据,随后对相关数据进行插入或修改,那么在标准的SLELECT中不会给出足够的保护。在你查询期间另一个事务可以更新或者删除相同的行。InnoDB提供两种类型的加锁读: SELECT ... LOCK IN SHARE MODE 给读到的每一行都 阅读全文
posted @ 2018-01-10 18:31 废物大师兄 阅读(3201) 评论(0) 推荐(0)
摘要: Consistent Nonlocking Reads 一致读意味着InnoDB用多版本来提供一个查询数据库某个时间点的快照。这种查询可以看到在当前世界点之前事务提交的改变,看不到此后提交的改变,更看不到未提交的改变。这个规则有一种例外情况是它可以看到同一个事务中在这个查询之前的改变。这种异常就造成 阅读全文
posted @ 2018-01-10 18:10 废物大师兄 阅读(433) 评论(1) 推荐(0)
摘要: 共享锁和排它锁 InnoDB实现了标准的行级锁,包括两种类型:共享锁(S)和排它锁(X) 一个共享锁(S)允许事务持有这种锁来读取一行 一个排它锁(X)允许事务持有这种锁来修改或删除一行 如果事务T1对行r持有一个共享锁(S),那么来自其它事务T的对于行r的锁的请求处理如下: 如果T2请求的是共享锁 阅读全文
posted @ 2018-01-10 16:47 废物大师兄 阅读(411) 评论(0) 推荐(0)