深入并发包 ConcurrentHashMap

原文出处: pettyandydog
前言
以前写过介绍HashMap的文章,文中提到过HashMap在put的时候,插入的元素超过了容量(由负载因子决定)的范围就会触发扩容操作,就是rehash,这个会重新将原数组的内容重新hash到新的扩容数组中,在多线程的环境下,存在同时其他的元素也在进行put操作,如果hash值相同,可能出现同时在同一数组下用链表表示,造成闭环,导致在get时会出现死循环,所以HashMap是线程不安全的。

我们来了解另一个键值存储集合HashTable,它是线程安全的,它在所有涉及到多线程操作的都加上了synchronized关键字来锁住整个table,这就意味着所有的线程都在竞争一把锁,在多线程的环境下,它是安全的,但是无疑是效率低下的。

其实HashTable有很多的优化空间,锁住整个table这么粗暴的方法可以变相的柔和点,比如在多线程的环境下,对不同的数据集进行操作时其实根本就不需要去竞争一个锁,因为他们不同hash值,不会因为rehash造成线程不安全,所以互不影响,这就是锁分离技术,将锁的粒度降低,利用多个锁来控制多个小的table,这就是这篇文章的主角ConcurrentHashMap JDK1.7版本的核心思想。

ConcurrentHashMap
JDK1.7的实现
在JDK1.7版本中,ConcurrentHashMap的数据结构是由一个Segment数组和多个HashEntry组成,如下图所示:

Segment数组的意义就是将一个大的table分割成多个小的table来进行加锁,也就是上面的提到的锁分离技术,而每一个Segment元素存储的是HashEntry数组+链表,这个和HashMap的数据存储结构一样

初始化
ConcurrentHashMap的初始化是会通过位与运算来初始化Segment的大小,用ssize来表示,如下所示

int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
ssize <<= 1;
}

如上所示,因为ssize用位于运算来计算(ssize <<=1),所以Segment的大小取值都是以2的N次方,无关concurrencyLevel的取值,当然concurrencyLevel最大只能用16位的二进制来表示,即65536,换句话说,Segment的大小最多65536个,没有指定concurrencyLevel元素初始化,Segment的大小ssize默认为16

每一个Segment元素下的HashEntry的初始化也是按照位于运算来计算,用cap来表示,如下所示

int cap = 1;
while (cap < c)
cap <<= 1;
如上所示,HashEntry大小的计算也是2的N次方(cap <<=1), cap的初始值为1,所以HashEntry最小的容量为2

put操作
对于ConcurrentHashMap的数据插入,这里要进行两次Hash去定位数据的存储位置

1
static class Segment extends ReentrantLock implements Serializable {
从上Segment的继承体系可以看出,Segment实现了ReentrantLock,也就带有锁的功能,当执行put操作时,会进行第一次key的hash来定位Segment的位置,如果该Segment还没有初始化,即通过CAS操作进行赋值,然后进行第二次hash操作,找到相应的HashEntry的位置,这里会利用继承过来的锁的特性,在将数据插入指定的HashEntry位置时(链表的尾端),会通过继承ReentrantLock的tryLock()方法尝试去获取锁,如果获取成功就直接插入相应的位置,如果已经有线程获取该Segment的锁,那当前线程会以自旋的方式去继续的调用tryLock()方法去获取锁,超过指定次数就挂起,等待唤醒。

get操作
ConcurrentHashMap的get操作跟HashMap类似,只是ConcurrentHashMap第一次需要经过一次hash定位到Segment的位置,然后再hash定位到指定的HashEntry,遍历该HashEntry下的链表进行对比,成功就返回,不成功就返回null。

size操作
计算ConcurrentHashMap的元素大小是一个有趣的问题,因为他是并发操作的,就是在你计算size的时候,他还在并发的插入数据,可能会导致你计算出来的size和你实际的size有相差(在你return size的时候,插入了多个数据),要解决这个问题,JDK1.7版本用两种方案。

try {
for (;;) {
if (retries++ == RETRIES_BEFORE_LOCK) {
for (int j = 0; j < segments.length; ++j) ensureSegment(j).lock(); // force creation
}
sum = 0L;
size = 0;
overflow = false;
for (int j = 0; j < segments.length; ++j) {
Segment seg = segmentAt(segments, j);
if (seg != null) { sum += seg.modCount; int c = seg.count; if (c < 0 || (size += c) RETRIES_BEFORE_LOCK) {
for (int j = 0; j < segments.length; ++j)
segmentAt(segments, j).unlock();
}
}
第一种方案他会使用不加锁的模式去尝试多次计算ConcurrentHashMap的size,最多三次,比较前后两次计算的结果,结果一致就认为当前没有元素加入,计算的结果是准确的;
第二种方案是如果第一种方案不符合,他就会给每个Segment加上锁,然后计算ConcurrentHashMap的size返回。
JDK1.8的实现
JDK1.8的实现已经摒弃了Segment的概念,而是直接用Node数组+链表+红黑树的数据结构来实现,并发控制使用Synchronized和CAS来操作,整个看起来就像是优化过且线程安全的HashMap,虽然在JDK1.8中还能看到Segment的数据结构,但是已经简化了属性,只是为了兼容旧版本。

在深入JDK1.8的put和get实现之前要知道一些常量设计和数据结构,这些是构成ConcurrentHashMap实现结构的基础,下面看一下基本属性:

// node数组最大容量:2^30=1073741824
private static final int MAXIMUM_CAPACITY = 1 < 8 链表转换为红黑树
static final int TREEIFY_THRESHOLD = 8;
//树转链表阀值,小于等于6(tranfer时,lc、hc=0两个计数器分别++记录原bin、新binTreeNode数量,<=UNTREEIFY_THRESHOLD 则untreeify(lo))
static final int UNTREEIFY_THRESHOLD = 6;
static final int MIN_TREEIFY_CAPACITY = 64;
private static final int MIN_TRANSFER_STRIDE = 16;
private static int RESIZE_STAMP_BITS = 16;
// 2^15-1,help resize的最大线程数
private static final int MAX_RESIZERS = (1 < h)
p = pl;
else if (ph < h)
p = pr;
else if ((pk = p.key) == k || (pk != null && k.equals(pk)))
return p;
else if (pl == null)
p = pr;
else if (pr == null)
p = pl;
else if ((kc != null ||
(kc = comparableClassFor(k)) != null) &&
(dir = compareComparables(kc, k, pk)) != 0)
p = (dir h)
dir = -1;
else if (ph < h)
dir = 1;
else if ((kc == null &&
(kc = comparableClassFor(k)) == null) ||
(dir = compareComparables(kc, k, pk)) == 0)
dir = tieBreakOrder(k, pk);
TreeNode xp = p;
if ((p = (dir <= 0) ? p.left : p.right) == null) {
x.parent = xp;
if (dir = 0) { //表示该节点是链表结构
binCount = 1;
for (Node e = f;; ++binCount) {
K ek;
//这里涉及到相同的key进行put就会覆盖原先的value
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
e.val = value;
break;
}
Node pred = e;
if ((e = e.next) == null) { //插入链表尾部
pred.next = new Node(hash, key,
value, null);
break;
}
}
}
else if (f instanceof TreeBin) {//红黑树结构
Node p;
binCount = 2;
//红黑树结构旋转插入
if ((p = ((TreeBin)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
if (binCount != 0) { //如果链表的长度大于8时就会进行红黑树的转换
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
addCount(1L, binCount);//统计size,并且检查是否需要扩容
return null;
}
这个put的过程很清晰,对当前的table进行无条件自循环直到put成功,可以分成以下六步流程来概述。

如果没有初始化就先调用initTable()方法来进行初始化过程
如果没有hash冲突就直接CAS插入
如果还在进行扩容操作就先进行扩容
如果存在hash冲突,就加锁来保证线程安全,这里有两种情况,一种是链表形式就直接遍历到尾端插入,一种是红黑树就按照红黑树结构插入,
最后一个如果该链表的数量大于阈值8,就要先转换成黑红树的结构,break再一次进入循环
如果添加成功就调用addCount()方法统计size,并且检查是否需要扩容
现在我们来对每一步的细节进行源码分析,在第一步中,符合条件会进行初始化操作,我们来看看initTable()方法

/**
* Initializes table, using the size recorded in sizeCtl.
*/
private final Node[] initTable() {
Node[] tab; int sc;
while ((tab = table) == null || tab.length == 0) {//空的table才能进入初始化操作
if ((sc = sizeCtl) >> 2);//记录下次扩容的大小
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
在第二步中没有hash冲突就直接调用Unsafe的方法CAS插入该元素,进入第三步如果容器正在扩容,则会调用helpTransfer()方法帮助扩容,现在我们跟进helpTransfer()方法看看

/**
*帮助从旧的table的元素复制到新的table中
*/
final Node[] helpTransfer(Node[] tab, Node f) {
Node[] nextTab; int sc;
if (tab != null && (f instanceof ForwardingNode) &&
(nextTab = ((ForwardingNode)f).nextTable) != null) { //新的table nextTba已经存在前提下才能帮助扩容
int rs = resizeStamp(tab.length);
while (nextTab == nextTable && table == tab &&
(sc = sizeCtl) >> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || transferIndex 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
if (nextTab == null) { // initiating
try {
@SuppressWarnings("unchecked")
Node[] nt = (Node[])new Node[n <= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) stride ?
nextIndex – stride : 0))) {
bound = nextBound;
i = nextIndex – 1;
advance = false;
}
}
if (i = n || i + n >= nextn) {
int sc;
// 已经完成所有节点复制了
if (finishing) {
nextTable = null;
table = nextTab; // table 指向nextTable
sizeCtl = (n > 1); // sizeCtl阈值为原来的1.5倍
return; // 跳出死循环,
}
// CAS 更扩容阈值,在这里面sizectl值减一,说明新加入一个线程参与到扩容操作
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc – 1)) {
if ((sc – 2) != resizeStamp(n) <= 0 ,表示为链表节点
if (fh >= 0) {
// 构造两个链表 一个是原链表 另一个是原链表的反序排列
int runBit = fh & n;
Node lastRun = f;
for (Node p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
if (runBit == 0) {
ln = lastRun;
hn = null;
}
else {
hn = lastRun;
ln = null;
}
for (Node p = f; p != lastRun; p = p.next) {
int ph = p.hash; K pk = p.key; V pv = p.val;
if ((ph & n) == 0)
ln = new Node(ph, pk, pv, ln);
else
hn = new Node(ph, pk, pv, hn);
}
// 在nextTable i 位置处插上链表
setTabAt(nextTab, i, ln);
// 在nextTable i + n 位置处插上链表
setTabAt(nextTab, i + n, hn);
// 在table i 位置处插上ForwardingNode 表示该节点已经处理过了
setTabAt(tab, i, fwd);
// advance = true 可以执行–i动作,遍历节点
advance = true;
}
// 如果是TreeBin,则按照红黑树进行处理,处理逻辑与上面一致
else if (f instanceof TreeBin) {
TreeBin t = (TreeBin)f;
TreeNode lo = null, loTail = null;
TreeNode hi = null, hiTail = null;
int lc = 0, hc = 0;
for (Node e = t.first; e != null; e = e.next) {
int h = e.hash;
TreeNode p = new TreeNode
(h, e.key, e.val, null, null);
if ((h & n) == 0) {
if ((p.prev = loTail) == null)
lo = p;
else
loTail.next = p;
loTail = p;
++lc;
}
else {
if ((p.prev = hiTail) == null)
hi = p;
else
hiTail.next = p;
hiTail = p;
++hc;
}
}
// 扩容后树节点个数若<=6,将树转链表
ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
(hc != 0) ? new TreeBin(lo) : t;
hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
(lc != 0) ? new TreeBin(hi) : t;
setTabAt(nextTab, i, ln);
setTabAt(nextTab, i + n, hn);
setTabAt(tab, i, fwd);
advance = true;
}
}
}
}
}
}
扩容过程有点复杂,这里主要涉及到多线程并发扩容,ForwardingNode的作用就是支持扩容操作,将已处理的节点和空节点置为ForwardingNode,并发处理时多个线程经过ForwardingNode就表示已经遍历了,就往后遍历,下图是多线程合作扩容的过程:

介绍完扩容过程,我们再次回到put流程,在第四步中是向链表或者红黑树里加节点,到第五步,会调用treeifyBin()方法进行链表转红黑树的过程。

private final void treeifyBin(Node[] tab, int index) {
Node b; int n, sc;
if (tab != null) {
//如果整个table的数量小于64,就扩容至原来的一倍,不转红黑树了
//因为这个阈值扩容可以减少hash冲突,不必要去转红黑树
if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
tryPresize(n <= 0) {
synchronized (b) {
if (tabAt(tab, index) == b) {
TreeNode hd = null, tl = null;
for (Node e = b; e != null; e = e.next) {
//封装成TreeNode
TreeNode p =
new TreeNode(e.hash, e.key, e.val,
null, null);
if ((p.prev = tl) == null)
hd = p;
else
tl.next = p;
tl = p;
}
//通过TreeBin对象对TreeNode转换成红黑树
setTabAt(tab, index, new TreeBin(hd));
}
}
}
}
}
到第六步表示已经数据加入成功了,现在调用addCount()方法计算ConcurrentHashMap的size,在原来的基础上加一,现在来看看addCount()方法。

private final void addCount(long x, int check) {
CounterCell[] as; long b, s;
//更新baseCount,table的数量,counterCells表示元素个数的变化
if ((as = counterCells) != null ||
!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
CounterCell a; long v; int m;
boolean uncontended = true;
//如果多个线程都在执行,则CAS失败,执行fullAddCount,全部加入count
if (as == null || (m = as.length – 1) = 0) {
Node[] tab, nt; int n, sc;
while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
(n = tab.length) > RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0)
break;
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
transfer(tab, nt);
}
//当前线程发起库哦哦让操作,nextTable=null
else if (U.compareAndSwapInt(this, SIZECTL, sc,
(rs < 0 &&
(e = tabAt(tab, (n – 1) & h)) != null) {//读取首节点的Node元素
if ((eh = e.hash) == h) { //如果该节点就是首节点就返回
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
//hash值为负值表示正在扩容,这个时候查的是ForwardingNode的find方法来定位到nextTable来
//查找,查找到就返回
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
while ((e = e.next) != null) {//既不是首节点也不是ForwardingNode,那就往下遍历
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
ConcurrentHashMap的get操作的流程很简单,也很清晰,可以分为三个步骤来描述

计算hash值,定位到该table索引位置,如果是首节点符合就返回
如果遇到扩容的时候,会调用标志正在扩容节点ForwardingNode的find方法,查找该节点,匹配就返回
以上都不符合的话,就往下遍历节点,匹配就返回,否则最后就返回null
size操作
最后我们来看下例子中最后获取size的方式int size = map.size();,现在让我们看下size()方法

public int size() {
long n = sumCount();
return ((n (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :
(int)n);
}
final long sumCount() {
CounterCell[] as = counterCells; CounterCell a; //变化的数量
long sum = baseCount;
if (as != null) {
for (int i = 0; i < as.length; ++i) {
if ((a = as[i]) != null)
sum += a.value;
}
}
return sum;
}
在JDK1.8版本中,对于size的计算,在扩容和addCount()方法就已经有处理了,JDK1.7是在调用size()方法才去计算,其实在并发集合中去计算size是没有多大的意义的,因为size是实时在变的,只能计算某一刻的大小,但是某一刻太快了,人的感知是一个时间段,所以并不是很精确。

总结与思考
其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap,相对而言,ConcurrentHashMap只是增加了同步的操作来控制并发,从JDK1.7版本的ReentrantLock+Segment+HashEntry,到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言,总结如下思考:

JDK1.8的实现降低锁的粒度,JDK1.7版本锁的粒度是基于Segment的,包含多个HashEntry,而JDK1.8锁的粒度就是HashEntry(首节点)
JDK1.8版本的数据结构变得更加简单,使得操作也更加清晰流畅,因为已经使用synchronized来进行同步,所以不需要分段锁的概念,也就不需要Segment这种数据结构了,由于粒度的降低,实现的复杂度也增加了
JDK1.8使用红黑树来优化链表,基于长度很长的链表的遍历是一个很漫长的过程,而红黑树的遍历效率是很快的,代替一定阈值的链表,这样形成一个最佳拍档
JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock,我觉得有以下几点:
因为粒度降低了,在相对而言的低粒度加锁方式,synchronized并不比ReentrantLock差,在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界,更加的灵活,而在低粒度中,Condition的优势就没有了
JVM的开发团队从来都没有放弃synchronized,而且基于JVM的synchronized优化空间更大,使用内嵌的关键字比使用API更加自然
在大量的数据操作下,对于JVM的内存压力,基于API的ReentrantLock会开销更多的内存,虽然不是瓶颈,但是也是一个选择依据
参考
http://blog.csdn.net/u010412719/article/details/52145145
http://www.jianshu.com/p/e694f1e868ec
https://my.oschina.net/liuxiaomian/blog/880088
https://bentang.me/tech/2016/12/01/jdk8-concurrenthashmap-1/
http://cmsblogs.com/?p=2283

从分布式一致性谈到CAP理论、BASE理论

转自:https://www.cnblogs.com/szlbm/p/5588543.html

问题的提出

在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景。

1、火车站售票

假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车 票,然后拿着车票去检票口,再坐上火车,开始一段美好的旅行—-一切似乎都是那么和谐。想象一下,如果他选择的目的地是杭州,而某一趟开往杭州的火车 只剩下最后一张车票,可能在同一时刻,不同售票窗口的另一位乘客也购买了同一张车票。假如说售票系统没有进行一致性的保障,两人都购票成功了。而在检票口 检票的时候,其中一位乘客会被告知他的车票无效—-当然,现代的中国铁路售票系统已经很少出现这样的问题了。但在这个例子中我们可以看出,终端用户对 于系统的需求非常简单:

“请售票给我,如果没有余票了,请在售票的时候就告诉我票是无效的”

这就对购票系统提出了严格的一致性要求—-系统的数据(本例中指的就是那趟开往杭州的火车的余票数)无论在哪个售票窗口,每时每刻都必须是准确无误的!

2、银行转账

假如我们的终端用户是一位刚毕业的大学生,通常在拿到第一个月工资的时候,都会选 择向家里汇款。当他来到银行柜台,完成转账操作后,银行的柜台服务员会友善地提醒他:”您的转账将在N个工作日后到账!”。此时这名毕业生有一定的沮丧, 会对那名柜台服务员叮嘱:”好吧,多久没关系,钱不要少就好了!”—-这也成为了几乎所有用户对于现代银行系统最基本的需求

3、网上购物

假如说我们的终端用户是一位网购达人,当他看见一件库存量为5的心仪商品,会迅速地确认购买,写下收货地址,然后下单—-然而,在下单的那个瞬间,系统可能会告知该用户:”库存量不足!”。此时绝大部分消费者都会抱怨自己动作太慢,使得心爱的商品被其他人抢走了。

但其实有过网购系统开发经验的工程师一定明白,在商品详情页上显示的那个库存量,通常不是该商品的真实库存量,只有在真正下单购买的时候,系统才会检查该商品的真实库存量。但是,谁在意呢?

问题的解读

对于上面三个例子,相信大家一定看出来了,我们的终端用户在使用不同的计算机产品时对于数据一致性的需求是不一样的:

1、有些系统,既要快速地响应用户,同时还要保证系统的数据对于任意客户端都是真实可靠的,就像火车站售票系统

2、有些系统,需要为用户保证绝对可靠的数据安全,虽然在数据一致性上存在延时,但最终务必保证严格的一致性,就像银行的转账系统

3、有些系统,虽然向用户展示了一些可以说是”错误”的数据,但是在整个系统使用过程中,一定会在某一个流程上对系统数据进行准确无误的检查,从而避免用户发生不必要的损失,就像网购系统

分布一致性的提出

在分布式系统中要解决的一个重要问题就是数据的复制。在我们的日常开发经验中,相 信很多开发人员都遇到过这样的问题:假设客户端C1将系统中的一个值K由V1更新为V2,但客户端C2无法立即读取到K的最新值,需要在一段时间之后才能 读取到。这很正常,因为数据库复制之间存在延时。

分布式系统对于数据的复制需求一般都来自于以下两个原因:

1、为了增加系统的可用性,以防止单点故障引起的系统不可用

2、提高系统的整体性能,通过负载均衡技术,能够让分布在不同地方的数据副本都能够为用户提供服务

数据复制在可用性和性能方面给分布式系统带来的巨大好处是不言而喻的,然而数据复制所带来的一致性挑战,也是每一个系统研发人员不得不面对的。

所谓分布一致性问题,是指在分布式环境中引入数据复制机制之后,不同数据节点之间 可能出现的,并无法依靠计算机应用程序自身解决的数据不一致的情况。简单讲,数据一致性就是指在对一个副本数据进行更新的时候,必须确保也能够更新其他的 副本,否则不同副本之间的数据将不一致。

那么如何解决这个问题?一种思路是”既然是由于延时动作引起的问题,那我可以将写入的动作阻塞,直到数据复制完成后,才完成写入动作”。 没错,这似乎能解决问题,而且有一些系统的架构也确实直接使用了这个思路。但这个思路在解决一致性问题的同时,又带来了新的问题:写入的性能。如果你的应 用场景有非常多的写请求,那么使用这个思路之后,后续的写请求都将会阻塞在前一个请求的写操作上,导致系统整体性能急剧下降。

总得来说,我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此,如何既保证数据的一致性,同时又不影响系统运行的性能,是每一个分布式系统都需要重点考虑和权衡的。于是,一致性级别由此诞生:

1、强一致性

这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大

2、弱一致性

这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态

3、最终一致性

最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型

分布式环境的各种问题

分布式系统体系结构从其出现之初就伴随着诸多的难题和挑战:

1、通信异常

从集中式向分布式演变的过程中,必然引入网络因素,由于网络本身的不可靠性,因此 也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信,因此每次网络通信都会伴随着网络不可用的风险,网络光纤、路由器或是DNS等硬件设备或 是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外,即使分布式系统各个节点之间的网络通信能够正常进行,其延时也会大于单机操作。通常 我们认为现代计算机体系结构中,单机内存访问的延时在纳秒数量级(通常是10ns),而正常的一次网络通信的延迟在0.1~1ms左右(相当于内存访问延 时的105倍),如此巨大的延时差别,也会影响到消息的收发过程,因此消息丢失和消息延迟变得非常普遍

2、网络分区

当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够正常通信,而另一些节点则不能—-我们将这个现象称为网络分区。当网络分区出现时,分布式系统会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能,包括对数据的事物处理,这就对分布式一致性提出了非常大的挑战

3、三态

上面两点,我们已经了解到在分布式环境下,网络可能会出现各式各样的问题,因此分布式系统的每一次请求与响应,存在特有的三态概念,即成功、失败、超时。 在传统的单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应:成功或失败。而在分布式系统中,由于网络是不可靠的,虽然在绝大部分情况 下,网络通信也能够接受到成功或失败的响应,当时当网络出现异常的情况下,就可能会出现超时现象,通常有以下两种情况:

(1)由于网络原因,该请求并没有被成功地发送到接收方,而是在发送过程中就发生了消息丢失现象

(2)该请求成功地被接收方接收后,进行了处理,但是在将响应反馈给发送方的过程中,发生了消息丢失现象

当出现这样的超时现象时,网络通信的发起方是无法确定当前请求是否被成功处理的

4、节点故障

节点故障则是分布式环境下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或”僵死”现象,通常根据经验来说,每个节点都有可能出现故障,并且每天都在发生

分布式事物

随着分布式计算的发展,事物在分布式计算领域也得到了广泛的应用。在单机数据库中,我们很容易能够实现一套满足ACID特性的事物处理系统,但在分布式数据库中,数据分散在各台不同的机器上,如何对这些数据进行分布式的事物处理具有非常大的挑战。

分布式事物是指事物的参与者、支持事物的服务器、资源服务器以及事物管理器分别位于分布式系统的不同节点上,通常一个分布式事物中会涉及对多个数据源或业务系统的操作。

可以设想一个最典型的分布式事物场景:一个跨银行的转账操作涉及调用两个异地的银 行服务,其中一个是本地银行提供的取款服务,另一个则是目标银行提供的存款服务,这两个服务本身是无状态并且相互独立的,共同构成了一个完整的分布式事 物。如果从本地银行取款成功,但是因为某种原因存款服务失败了,那么就必须回滚到取款之前的状态,否则用户可能会发现自己的钱不翼而飞了。

从这个例子可以看到,一个分布式事务可以看做是多个分布式的操作序列组成的,例如 上面例子的取款服务和存款服务,通常可以把这一系列分布式的操作序列称为子事物。因此,分布式事务也可以被定义为一种嵌套型的事物,同时也就具有了 ACID事物特性。但由于在分布式事务中,各个子事物的执行是分布式的,因此要实现一种能够保证ACID特性的分布式事物处理系统就显得格外复杂。

CAP理论

一个经典的分布式系统理论。CAP理论告诉我们:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中两项。

1、一致性

在分布式环境下,一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一直的状态。

对于一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进 行了更新操作并且更新成功后,却没有使得第二个节点上的数据得到相应的更新,于是在对第二个节点的数据进行读取操作时,获取的依然是老数据(或称为脏数 据),这就是典型的分布式数据不一致的情况。在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到其最新的值,那么 这样的系统就被认为具有强一致性

2、可用性

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是”有限时间内”和”返回结果”。

“有限时间内”是指,对于用户的一个操作请求,系统必须能够在指定的时间内返回对 应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的。另外,”有限的时间内”是指系统设计之初就设计好的运行指标,通常不同系统之间有很 大的不同,无论如何,对于用户请求,系统必须存在一个合理的响应时间,否则用户便会对系统感到失望。

“返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。

3、分区容错性

分区容错性约束了一个分布式系统具有如下特性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络) 中,由于一些特殊的原因导致这些子网络出现网络不连通的状况,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域。 需要注意的是,组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点,所以我们就需要抛弃一样:

用一张表格说明一下:

选 择 说 明
CA 放弃分区容错性,加强一致性和可用性,其实就是传统的单机数据库的选择
AP 放弃一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择,例如很多NoSQL系统就是如此
CP 放弃可用性,追求一致性和分区容错性,基本不会选择,网络问题会直接让整个系统不可用
需要明确的一点是,对于一个分布式系统而言,分区容错性是一个最基本的要求。因为 既然是一个分布式系统,那么分布式系统中的组件必然需要被部署到不同的节点,否则也就无所谓分布式系统了,因此必然出现子网络。而对于分布式系统而言,网 络问题又是一个必定会出现的异常情况,因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。因此系统架构师往往需要把精力花在如何根据业务 特点在C(一致性)和A(可用性)之间寻求平衡。

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结, 是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素:

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性—-注意,这绝不等价于系统不可用。比如:

(1)响应时间上的损失。正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障,查询结果的响应时间增加了1~2秒

(2)系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面

2、软状态

软状态指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

总的来说,BASE理论面向的是大型高可用可扩展的分布式系统,和传统的事物ACID特性是相反的,它完全不同于ACID的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。但同时,在实际的分布式场景中,不同业务单元和组件对数据一致性的要求是不同的,因此在具体的分布式系统架构设计过程中,ACID特性和BASE理论往往又会结合在一起。

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

一、HTTP的历史

早在 HTTP 建立之初,主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说,我们所写的HTML页面将要放在我们的 web 服务器上,用户端通过浏览器访问url地址来获取网页的显示内容,但是到了 WEB2.0 以来,我们的页面变得复杂,不仅仅单纯的是一些简单的文字和图片,同时我们的 HTML 页面有了 CSS,Javascript,来丰富我们的页面展示,当 ajax 的出现,我们又多了一种向服务器端获取数据的方法,这些其实都是基于 HTTP 协议的。同样到了移动互联网时代,我们页面可以跑在手机端浏览器里面,但是和 PC 相比,手机端的网络情况更加复杂,这使得我们开始了不得不对 HTTP 进行深入理解并不断优化过程中。

二、HTTP的基本优化

影响一个 HTTP 网络请求的因素主要有两个:带宽和延迟。

带宽:如果说我们还停留在拨号上网的阶段,带宽可能会成为一个比较严重影响请求的问题,但是现在网络基础建设已经使得带宽得到极大的提升,我们不再会担心由带宽而影响网速,那么就只剩下延迟了。

延迟:

浏览器阻塞(HOL blocking):浏览器会因为一些原因阻塞请求。浏览器对于同一个域名,同时只能有 4 个连接(这个根据浏览器内核不同可能会有所差异),超过浏览器最大连接数限制,后续请求就会被阻塞。

DNS 查询(DNS Lookup):浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。

建立连接(Initial connection):HTTP 是基于 TCP 协议的,浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文,达到真正的建立连接,但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。

三、HTTP1.0和HTTP1.1的一些区别

HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:

缓存处理,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。

Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。

长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

四、HTTPS与HTTP的一些区别

HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。

HTTP协议运行在TCP之上,所有传输的内容都是明文,HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的。

HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

HTTPS可以有效的防止运营商劫持,解决了防劫持的一个大问题。

五、SPDY:HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案,优化了HTTP1.X的请求延迟,解决了HTTP1.X的安全性,具体如下:

降低延迟,针对HTTP高延迟的问题,SPDY优雅的采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接的方式,解决了HOL blocking的问题,降低了延迟同时提高了带宽的利用率。

请求优先级(request prioritization)。多路复用带来一个新的问题是,在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的html内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。

header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。

服务端推送(server push),采用了SPDY的网页,例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了。SPDY构成图:

SPDY位于HTTP之下,TCP和SSL之上,这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式),同时可以使用已有的SSL功能。

六、HTTP2.0性能惊人

HTTP/2: the Future of the Internet https://link.zhihu.com/?target=https://http2.akamai.com/demo 是 Akamai 公司建立的一个官方的演示,用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片,从Load time 的对比可以看出 HTTP/2 在速度上的优势。

七、HTTP2.0:SPDY的升级版

HTTP2.0可以说是SPDY的升级版(其实原本也是基于SPDY设计的),但是,HTTP2.0 跟 SPDY 仍有不同的地方,如下:

HTTP2.0和SPDY的区别:

HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS

HTTP2.0 消息头的压缩算法采用 HPACK http://http2.github.io/http2-spec/compression.html,而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE

八、HTTP2.0和HTTP1.X相比的新特性

新的二进制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。

多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

header压缩,如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。

服务端推送(server push),同SPDY一样,HTTP2.0也具有server push功能。

九、HTTP2.0的升级改造

前文说了HTTP2.0其实可以支持非HTTPS的,但是现在主流的浏览器像chrome,firefox表示还是只支持基于 TLS 部署的HTTP2.0协议,所以要想升级成HTTP2.0还是先升级HTTPS为好。

当你的网站已经升级HTTPS之后,那么升级HTTP2.0就简单很多,如果你使用NGINX,只要在配置文件中启动相应的协议就可以了,可以参考NGINX白皮书,NGINX配置HTTP2.0官方指南 https://www.nginx.com/blog/nginx-1-9-5/。

使用了HTTP2.0那么,原本的HTTP1.x怎么办,这个问题其实不用担心,HTTP2.0完全兼容HTTP1.x的语义,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容的。

十、附注

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别?

HTTP/1.* 一次请求-响应,建立一个连接,用完关闭;每一个请求都要建立一个连接;

HTTP/1.1 Pipeling解决方式为,若干个请求排队串行化单线程处理,后面的请求等待前面请求的返回才能获得执行机会,一旦有某请求超时等,后续请求只能被阻塞,毫无办法,也就是人们常说的线头阻塞;

HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重,不会影响到其它连接的正常执行;
具体如图:

服务器推送到底是什么?
服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端,省去了客户端重复请求的步骤。正因为没有发起请求,建立连接等操作,所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下:

普通的客户端请求过程:

服务端推送的过程:

为什么需要头部压缩?
假定一个页面有100个资源需要加载(这个数量对于今天的Web而言还是挺保守的), 而每一次请求都有1kb的消息头(这同样也并不少见,因为Cookie和引用等东西的存在), 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典,差量更新HTTP头部,大大降低因头部传输产生的流量。具体参考:HTTP/2 头部压缩技术介绍

HTTP2.0多路复用有多好?
HTTP 性能优化的关键并不在于高带宽,而是低延迟。TCP 连接会随着时间进行自我「调谐」,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因,让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接,可以更有效地使用 TCP 连接,让高带宽也能真正的服务于 HTTP 的性能提升。

十一、参考

HTTP/2.0 相比1.0有哪些重大改进?
深入研究:HTTP2 的真正性能到底如何
HTTP/2 头部压缩技术介绍

如何性能调优

文章来源 https://mp.weixin.qq.com/s/UaMkgwXmjTGyOn6XJMnanw

性能优化的常见概念

吞吐量(TPS, QPS):简单来说就是每秒钟完成的事务数或者查询数。通常吞吐量大表明系统单位时间能处理的请求数越多,所以通常希望TPS越高越好

响应时间:即从请求发出去到收到系统返回的时间。响应时间一般不取平均值,而是要去掉不稳定的值之后再取均值,比如常用的90%响应时间,指的就是去掉了10%不稳定的响应时间之后,剩下90%的稳定的响应时间的均值。从聚类的观点看,其实就是去掉离群点。

错误率:即错误请求数与总请求数之比。随着压力增加,有可能出现处理请求处理不过来的情况,这时错误数会不断增加。

三者有极大的关联,任何孤立的数据都不能说明问题。典型的关系是,吞吐量增加时,响应延迟有可能增加,错误率也有可能增加。因此,单拿出一个10w的TPS并不能说明问题。

性能调优的思路

一般情况,调优需要有个前提条件,即无论是用线上的真实流水还是线下的压力测试让问题扩大化,明显化。

根据这些比较明显的现象去初判问题,收集证据去验证初判结果成立,然后分析现象产生的原因,并尝试解决问题。

1.性能摸底测试

对于新上的系统或者是有过较大代码改动的系统来说,做一次摸底测试还是很有必要的。一般来说,期望摸底的测试是一次对单机的压力测试。压力测试可以帮你大概搞清楚系统的极限TPS是多少,在压力上来时有没有暴露一些错误或者问题,系统大致的资源占用情况是什么,系统可能的性能瓶颈在哪。

如下是一次摸底测试的配置和结果。这是用12000并发用户对10台机器压测的结果,可以看出,TPS到7w多,平均响应时间为82ms,错误率在2.5%。

从图中还可以得到哪些信息?首先,TPS在后期迅速下落,实际上已经支撑不了如此大的并发量,即进入崩溃区,这里有几个可能,一是系统根本承受不了如此大的并发量,二是系统中间有问题导致TPS下跌。其次,随着时间增长,错误率显著增加,说明系统已经处理不了如此多的请求。结合前面两点以及相对平稳的平均响应时间,大致可以推断系统没法承受如此大的并发。另外,由于是10台机器,单台的TPS大概在7000多,今后的调优可以以此为依据。

对于应用的特点,也要在这时候分析出来,即应用可能占用的资源。比如是CPU密集型应用还是IO密集型应用(还可以细分为是磁盘密集还是网络 )

2.定义性能优化的目标

经常听到人说,做个性能优化,吞吐量越高越好;或者做个性能测试,目标TPS是50000。可实际拿到这个信息,能够做性能测试吗?这个目标足够清晰吗?

事实上,在我看来,未定义清晰的目标去做性能测试都是耍流氓。

性能优化的目标一般是吞吐量达到多少,90%响应时间小于多少,错误率小于多少。同时还需要关注其他的性能指标,cpu使用情况,内存使用情况,磁盘使用情况,带宽使用情况等。对于摸底测试已经发现问题的,可以针对该问题专门优化,比如负载较高,cpu消耗过大,则目标可能是TPS,响应时间以及错误率不变的情况下降低CPU负载。或者内存增长过快,gc较为频繁,则目标可能是找出可能的内存泄露,或者进行相关的jvm内存调优。总之,目标可以比较灵活调整,但一定要明确。

3.分析

分析的过程较为灵活,基本上是一千个系统有一千种表现。这里很难一一说明。仅谈谈一些常见的方法,工具以及思路。

针对CPU:

针对cpu的监控,其实linux已经提供了两个比较好用的工具,一个是top,一个是vmstat。关于这两个命令就不细说了,参考这里top(http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/top.html),vmstat(http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/vmstat.html)

关于cpu主要关注4个值:us(user), sy(system), wa(wait), id(idle)。理论上他们加起来应该等于100%。而前三个每一个值过高都有可能表示存在某些问题。

us过高:

a. 代码问题。比如一个耗时的循环不加sleep,或者在一些cpu密集计算(如xml解析,加解密,加解压,数据计算)时没处理好

b. gc频繁。一个比较容易遗漏的问题就是gc频繁时us容易过高,因为垃圾回收属于大量计算的过程。gc频繁带来的cpu过高常伴有内存的大量波动,通过内存来判断并解决该问题更好。

小技巧:如何定位us过高的线程并查看它的状态。

a. top命令找到消耗us过高的进程pid

b. top -Hp pid找到对应的线程tid

c. printf %x tid转为16进制tid16

d. jstack pid | grep -C 20 tid16 即可查到该线程堆栈

sy过高:

a. 上下文切换次数过多。通常是系统内线程数量较多,并且线程经常在切换,由于系统抢占相对切换时间和次数比较合理,所以sy过高通常都是主动让出cpu的情况,比如sleep或者lock wait, io wait。

wa过高:

a. 等待io的cpu占比较多。注意与上面情况的区别,io wait引起的sy过高指的是io不停的wait然后唤醒,因为数量较大,导致上下文切换较多,强调的是动态的过程;而io wait引起的wa过高指的是io wait的线程占比较多,cpu切换到这个线程是io wait,到那个线程也是io wait,于是总cpu就是wait占比较高。

id过高:

a. 很多人认为id高是好的,其实在性能测试中id高说明资源未完全利用,或者压测不到位,并不是好事。

针对内存:

关于java应用的内存,通常只需要关注jvm内存,但有些特殊情况也需要关注物理内存。关于jvm内存,常见的工具有jstat(http://blog.csdn.net/fenglibing/article/details/6411951), jmap(http://www.cnblogs.com/ggjucheng/archive/2013/04/16/3024986.html), pidstat(https://linux.cn/article-4257-1.html), vmstat, top

jvm内存:

异常gc :

a. 通常gc发生意味着总归是有一块区域空间不足而触发gc。而许多导致异常gc的情况通常是持有了不必要的引用而没有即时的释放,比如像cache这样的地方就容易处理不好导致内存泄露引发异常gc。

b. 有可能是程序的行为是正常的,但是由于没有配置对合适的gc参数导致异常gc,这种情况通常需要调优gc参数或者堆代大小参数。

c. Full gc 发生的情况:

永久代满

年老代满

minor gc晋升到旧生代的平均大小大于旧生代剩余大小

CMS gc中promotion fail或concurrent mode fail

OOM:

a. OOM经常伴随着异常gc,之所以单独拿出来讲,是因为它的危害更大一些,异常gc顶多是收集速度过快或者回收不了内存,但是起码有个缓冲时间,但是出了OOM问题就大了。至于各种类型的OOM如何区分,如何发生,请参考这里(http://www.jianshu.com/p/2fdee831ed03),算是总结得比较全面的。对于常见的OOM,基本上可以一下子指出问题所在。

b. heap区,对象创建过多或持有太多无效引用(泄露)或者堆内存分配不足。使用jmap找到内存中对象的分布,使用ps找到相应进程及初始内存配置。

c. stack区, 不正确的递归调用。

d. perm区,初始加载包过多,分配内存不足。

e. 堆外内存区,分配ByteBuffer未释放导致。

针对IO:

IO分为网络IO和文件IO,针对网络IO比较有用的工具有sar(https://linuxstory.org/generate-cpu-memory-io-report-sar-command/),netstat(https://linux.cn/article-2434-1.html),netstat是一个非常牛逼的命令,可以助于排查很多问题, 针对文件io的工具有pidstat,iostat(http://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/iostat.html)

文件IO:

a. 从技术上来说,对于大文件IO可以采取的措施是异步批处理,采用异步方式用于削峰并累计buffer,采用批处理能够让磁盘寻道连续从而更加快速。

网络IO:网络IO的问题较为复杂,仅举几个常见的

a. 大量TIME_WAIT。根据TCP协议,主动发起关闭连接的那一方,关闭了自己这端的连接后再收到被动发起关闭的那一方的关闭请求后,会将状态变为TIME_WAIT,并等待2MSL, 目的是等待自己的回执发送到对方。如果在服务器上发现大量TIME_WAIT,说明服务器主动断开了连接,什么情况下服务器会主动断开连接,很可能是客户端忘了断开连接,所以一个典型的案例就是jdbc连接忘记关闭,则数据库服务器可能会出现大量的TIME_WAIT状态。

b. 大量CLOSE_WAIT。CLOSE_WAIT状态,在收到主动关闭连接的一方发出关闭连接之后,被动关闭的一方进入CLOSE_WAIT状态,如果这时候被hang住了没进行后续关闭,则会出现大量CLOSE_WAIT。啥情况会被hang住呢,举几个例子,比如刚刚的忘记关闭数据库连接,在应用服务器这端,大量的浏览器请求进来,由于没有连接池连接被hang住,这时候浏览器等待一定时间超时发送关闭连接请求,而应用服务器这边由于servlet线程被hang住了,自然没有办法走第二个关闭回去。因此在应用服务器出现大量CLOSE_WAIT。另一个例子是httpClient的坑,在调用response.getEntity(); 前都不会做inputStream.close(),如果在调用response.getEntity()前就返回了,就狗带了。(这个例子可以参考http://blog.csdn.net/shootyou/article/details/6615051)

4.优化并重新测试验证

性能调优思路 http://www.voidcn.com/blog/bigtree_3721/article/p-5786972.html

linux下性能监控命令 http://linuxtools-rst.readthedocs.io/zh_CN/latest/advance/index.html

关于JVM CPU资源占用过高的问题排查 http://my.oschina.net/shipley/blog/520062

java排查工具 http://my.oschina.net/feichexia/blog/196575

jvm参数调优 http://www.cnblogs.com/java-zhao/archive/2016/02/08/5185092.html

java linux系统调优工具 https://www.ibm.com/developerworks/cn/java/j-lo-performance-tuning-practice/

gc优化的一些思路 http://mm.fancymore.com/reading/gc%E4%BC%98%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%B7%AF.html

性能优化的思路和步骤 http://www.uml.org.cn/j2ee/201602013.asp

性能调优攻略 http://coolshell.cn/articles/7490.html

JVM性能调优入门 http://www.jianshu.com/p/c6a04c88900a

JVM性能调优 http://blog.csdn.net/chen77716/article/details/5695893

Tomcat性能优化 https://yq.aliyun.com/articles/38861?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&2017323&utm_content=m_14698

Java四种引用包括强引用,软引用,弱引用,虚引用

转自:https://www.cnblogs.com/yw-ah/p/5830458.html

强引用:

只要引用存在,垃圾回收器永远不会回收
Object obj = new Object();
//可直接通过obj取得对应的对象 如obj.equels(new Object());
而这样 obj对象对后面new Object的一个强引用,只有当obj这个引用被释放之后,对象才会被释放掉,这也是我们经常所用到的编码形式。

软引用:

非必须引用,内存溢出之前进行回收,可以通过以下代码实现
Object obj = new Object();
SoftReference sf = new SoftReference(obj);
obj = null;
sf.get();//有时候会返回null
这时候sf是对obj的一个软引用,通过sf.get()方法可以取到这个对象,当然,当这个对象被标记为需要回收的对象时,则返回null;
软引用主要用户实现类似缓存的功能,在内存足够的情况下直接通过软引用取值,无需从繁忙的真实来源查询数据,提升速度;当内存不足时,自动删除这部分缓存数据,从真正的来源查询这些数据。

弱引用:

第二次垃圾回收时回收,可以通过如下代码实现
Object obj = new Object();
WeakReference wf = new WeakReference(obj);
obj = null;
wf.get();//有时候会返回null
wf.isEnQueued();//返回是否被垃圾回收器标记为即将回收的垃圾
弱引用是在第二次垃圾回收时回收,短时间内通过弱引用取对应的数据,可以取到,当执行过第二次垃圾回收时,将返回null。
弱引用主要用于监控对象是否已经被垃圾回收器标记为即将回收的垃圾,可以通过弱引用的isEnQueued方法返回对象是否被垃圾回收器标记。

虚引用:

垃圾回收时回收,无法通过引用取到对象值,可以通过如下代码实现
Object obj = new Object();
PhantomReference pf = new PhantomReference(obj);
obj=null;
pf.get();//永远返回null
pf.isEnQueued();//返回是否从内存中已经删除
虚引用是每次垃圾回收的时候都会被回收,通过虚引用的get方法永远获取到的数据为null,因此也被成为幽灵引用。
虚引用主要用于检测对象是否已经从内存中删除。

最近在学习Java虚拟机,碰到引用的问题,在此借鉴总结一下:

原文地址:http://blog.csdn.net/coding_or_coded/article/details/6603549

对象的强、软、弱和虚引用
在JDK 1.2以前的版本中,若一个对象不被任何变量引用,那么程序就无法再使用这个对象。也就是说,只有对象处于可触及(reachable)状态,程序才能使用它。从JDK 1.2版本开始,把对象的引用分为4种级别,从而使程序能更加灵活地控制对象的生命周期。这4种级别由高到低依次为:强引用、软引用、弱引用和虚引用。

⑴强引用(StrongReference)
强引用是使用最普遍的引用。如果一个对象具有强引用,那垃圾回收器绝不会回收它。当内存空间不足,Java虚拟机宁愿抛出OutOfMemoryError错误,使程序异常终止,也不会靠随意回收具有强引用的对象来解决内存不足的问题。 ps:强引用其实也就是我们平时A a = new A()这个意思。

⑵软引用(SoftReference)
如果一个对象只具有软引用,则内存空间足够,垃圾回收器就不会回收它;如果内存空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存(下文给出示例)。
软引用可以和一个引用队列(ReferenceQueue)联合使用,如果软引用所引用的对象被垃圾回收器回收,Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

⑶弱引用(WeakReference)
弱引用与软引用的区别在于:只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。不过,由于垃圾回收器是一个优先级很低的线程,因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列(ReferenceQueue)联合使用,如果弱引用所引用的对象被垃圾回收,Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

⑷虚引用(PhantomReference)
“虚引用”顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于:虚引用必须和引用队列 (ReferenceQueue)联合使用。当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象的内存之前,把这个虚引用加入到与之 关联的引用队列中。

ReferenceQueue queue = new ReferenceQueue ();

PhantomReference pr = new PhantomReference (object, queue);

程序可以通过判断引用队列中是否已经加入了虚引用,来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列,那么就可以在所引用的对象的内存被回收之前采取必要的行动。

Java中的String,StringBuilder,StringBuffer三者的区别

转自:https://www.cnblogs.com/su-feng/p/6659064.html
这三个类之间的区别主要是在两个方面,即运行速度和线程安全这两方面。

首先说运行速度,或者说是执行速度,在这方面运行速度快慢为:StringBuilder > StringBuffer > String
  String最慢的原因:

  String为字符串常量,而StringBuilder和StringBuffer均为字符串变量,即String对象一旦创建之后该对象是不可更改的,但后两者的对象是变量,是可以更改的。以下面一段代码为例:

1 String str=”abc”;
2 System.out.println(str);
3 str=str+”de”;
4 System.out.println(str);

  如果运行这段代码会发现先输出“abc”,然后又输出“abcde”,好像是str这个对象被更改了,其实,这只是一种假象罢了,JVM对于这几行代码是这样处理的,首先创建一个String对象str,并把“abc”赋值给str,然后在第三行中,其实JVM又创建了一个新的对象也名为str,然后再把原来的str的值和“de”加起来再赋值给新的str,而原来的str就会被JVM的垃圾回收机制(GC)给回收掉了,所以,str实际上并没有被更改,也就是前面说的String对象一旦创建之后就不可更改了。所以,Java中对String对象进行的操作实际上是一个不断创建新的对象并且将旧的对象回收的一个过程,所以执行速度很慢。

  而StringBuilder和StringBuffer的对象是变量,对变量进行操作就是直接对该对象进行更改,而不进行创建和回收的操作,所以速度要比String快很多。

  另外,有时候我们会这样对字符串进行赋值

1 String str=”abc”+”de”;
2 StringBuilder stringBuilder=new StringBuilder().append(“abc”).append(“de”);
3 System.out.println(str);
4 System.out.println(stringBuilder.toString());
  这样输出结果也是“abcde”和“abcde”,但是String的速度却比StringBuilder的反应速度要快很多,这是因为第1行中的操作和

  String str=”abcde”;

  是完全一样的,所以会很快,而如果写成下面这种形式

1 String str1=”abc”;
2 String str2=”de”;
3 String str=str1+str2;
  那么JVM就会像上面说的那样,不断的创建、回收对象来进行这个操作了。速度就会很慢。

  2. 再来说线程安全

  在线程安全上,StringBuilder是线程不安全的,而StringBuffer是线程安全的

  如果一个StringBuffer对象在字符串缓冲区被多个线程使用时,StringBuffer中很多方法可以带有synchronized关键字,所以可以保证线程是安全的,但StringBuilder的方法则没有该关键字,所以不能保证线程安全,有可能会出现一些错误的操作。所以如果要进行的操作是多线程的,那么就要使用StringBuffer,但是在单线程的情况下,还是建议使用速度比较快的StringBuilder。

  3. 总结一下
  String:适用于少量的字符串操作的情况

  StringBuilder:适用于单线程下在字符缓冲区进行大量操作的情况

  StringBuffer:适用多线程下在字符缓冲区进行大量操作的情况

五分钟理解一致性哈希算法(consistent hashing)

    一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得分布式哈希(DHT)可以在P2P环境中真正得到应用。
    一致性hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义:
1、平衡性(Balance):平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。
3、分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生,也就是尽量降低分散性。
4、负载(Load):负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中,那么对于一个特定的缓冲区而言,也可能被不同的用户映射为不同 的内容。与分散性一样,这种情况也是应当避免的,因此好的哈希算法应能够尽量降低缓冲的负荷。
    在分布式集群中,对机器的添加删除,或者机器故障后自动脱离集群这些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法,那么在有机器添加或者删除后,很多原有的数据就无法找到了,这样严重的违反了单调性原则。接下来主要讲解一下一致性哈希算法是如何设计的:
环形Hash空间
按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中,即0~(2^32)-1的数字空间中。现在我们可以将这些数字头尾相连,想象成一个闭合的环形。如下图
                                                                         
把数据通过一定的hash算法处理后映射到环上
现在我们将object1、object2、object3、object4四个对象通过特定的Hash函数计算出对应的key值,然后散列到Hash环上。如下图:
    Hash(object1) = key1;
    Hash(object2) = key2;
    Hash(object3) = key3;
    Hash(object4) = key4;
                                                           
将机器通过hash算法映射到环上
在采用一致性哈希算法的分布式集群中将新的机器加入,其原理是通过使用与对象存储一样的Hash算法将机器也映射到环中(一般情况下对机器的hash计算是采用机器的IP或者机器唯一的别名作为输入值),然后以顺时针的方向计算,将所有对象存储到离自己最近的机器中。
假设现在有NODE1,NODE2,NODE3三台机器,通过Hash算法得到对应的KEY值,映射到环中,其示意图如下:
Hash(NODE1) = KEY1;
Hash(NODE2) = KEY2;
Hash(NODE3) = KEY3;
                                                             
通过上图可以看出对象与机器处于同一哈希空间中,这样按顺时针转动object1存储到了NODE1中,object3存储到了NODE2中,object2、object4存储到了NODE3中。在这样的部署环境中,hash环是不会变更的,因此,通过算出对象的hash值就能快速的定位到对应的机器中,这样就能找到对象真正的存储位置了。
机器的删除与添加
普通hash求余算法最为不妥的地方就是在有机器的添加或者删除之后会照成大量的对象存储位置失效,这样就大大的不满足单调性了。下面来分析一下一致性哈希算法是如何处理的。
1. 节点(机器)的删除
    以上面的分布为例,如果NODE2出现故障被删除了,那么按照顺时针迁移的方法,object3将会被迁移到NODE3中,这样仅仅是object3的映射位置发生了变化,其它的对象没有任何的改动。如下图:
                                                              
2. 节点(机器)的添加
    如果往集群中添加一个新的节点NODE4,通过对应的哈希算法得到KEY4,并映射到环中,如下图:
                                                              
    通过按顺时针迁移的规则,那么object2被迁移到了NODE4中,其它对象还保持这原有的存储位置。通过对节点的添加和删除的分析,一致性哈希算法在保持了单调性的同时,还是数据的迁移达到了最小,这样的算法对分布式集群来说是非常合适的,避免了大量数据迁移,减小了服务器的的压力。
平衡性
根据上面的图解分析,一致性哈希算法满足了单调性和负载均衡的特性以及一般hash算法的分散性,但这还并不能当做其被广泛应用的原由,因为还缺少了平衡性。下面将分析一致性哈希算法是如何满足平衡性的。hash算法是不保证平衡的,如上面只部署了NODE1和NODE3的情况(NODE2被删除的图),object1存储到了NODE1中,而object2、object3、object4都存储到了NODE3中,这样就照成了非常不平衡的状态。在一致性哈希算法中,为了尽可能的满足平衡性,其引入了虚拟节点。
    ——“虚拟节点”( virtual node )是实际节点(机器)在 hash 空间的复制品( replica ),一实际个节点(机器)对应了若干个“虚拟节点”,这个对应个数也成为“复制个数”,“虚拟节点”在 hash 空间中以hash值排列。
以上面只部署了NODE1和NODE3的情况(NODE2被删除的图)为例,之前的对象在机器上的分布很不均衡,现在我们以2个副本(复制个数)为例,这样整个hash环中就存在了4个虚拟节点,最后对象映射的关系图如下:
                                                                 
根据上图可知对象的映射关系:object1->NODE1-1,object2->NODE1-2,object3->NODE3-2,object4->NODE3-1。通过虚拟节点的引入,对象的分布就比较均衡了。那么在实际操作中,正真的对象查询是如何工作的呢?对象从hash到虚拟节点到实际节点的转换如下图:
                                         
“虚拟节点”的hash计算可以采用对应节点的IP地址加数字后缀的方式。例如假设NODE1的IP地址为192.168.1.100。引入“虚拟节点”前,计算 cache A 的 hash 值:
Hash(“192.168.1.100”);
引入“虚拟节点”后,计算“虚拟节”点NODE1-1和NODE1-2的hash值:
Hash(“192.168.1.100#1”); // NODE1-1
Hash(“192.168.1.100#2”); // NODE1-2

邮件服务优化方案(2018年3月23日)

Skip to end of metadata

 

Go to start of metadata

 

 

 

一、问题

1、report耗时

从目前来看,一次report的耗时从1个半小时到2个小时不等,时间略长。每次report的邮件数从3万-6万不等,得出这个数据的过程可以参考附件。

2、内存

不仅仅是邮件服务,JVM老年代内存逐渐上涨直至报警,需要重启来解决的问题在各个系统中几乎全部存在,只不过邮件服务的迭代周期较长(重启的次数很低),所以报警问题较为突出。

二、分析

1、report

工作的线程模型可以用下图来表示:

阶段一

阶段一在定时任务线程中执行,这一步所做的工作是从数据库中一次性查出最近3天内需要进行report的所有邮件(总数在3万-6万不等),并提交到pull线程池中。

阶段二

直接上源码,MailReportPullJobs.doPull:

for (MailReports mailReports : reportList) {
    executor.execute(() -> {
        MailReportRequest mailReportRequest = new MailReportRequest();
        String messageId = mailReports.getMessageId();
        mailReportRequest.setMessageId(messageId);
        //为了兼容老数据,需要去mails表里查询toMail字段
        String recipient = "";
        if(StringUtils.isBlank(mailReports.getToMail())){
            Mails mail = mailService.getMails(mailReports.getMailId());
            recipient = mail != null ? mail.getToMail() : "";
        }else{
            recipient = mailReports.getToMail();
        }
        mailReportRequest.setRecipient(recipient);
        if(StringUtils.isNotBlank(messageId) && StringUtils.isNotBlank(recipient)) {
            mailStrategy.doPullReport(mailReportRequest, mailReports.getId());
        }
    });
}

由于在当前的数据中可以直接获得toMail,所以这里不会进行一次数据库查询,即:全部是简单的、步骤有限的内存操作,所以可以进一步得出推论:这个pull线程池没有存在的必要

下面是此线程池的定义:

private static final ThreadPoolExecutor executor =
        new ThreadPoolExecutor(Runtime.getRuntime().availableProcessors(), Runtime.getRuntime().availableProcessors() * 10, 0L, TimeUnit.MILLISECONDS,
        new LinkedBlockingQueue<>(), ThreadUtils.newThreadFactoryByName("pullExecutor"));

由于队列大小上限是int最大值,考虑到目前需要report的邮件数远小于此值,所以此时线程池maximumPoolSize参数实际上失去了意义,即线程数永远不会达到此值

Q: Why?

A: 参考ThreadPoolExecutor的execute方法源码:

public void execute(Runnable command) {
    int c = ctl.get();
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        if (! isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(nullfalse);
    }
    else if (!addWorker(command, false))
        reject(command);
}

概括来说,一个任务被提交的步骤是:

  1. 如果当前线程数未达到corePoolSize,提升线程数,并将任务直接交给新创建的线程池执行。
  2. 如果已达到corePoolSize,那么尝试提交到任务队列,如果提交成功,返回。
  3. 如果线程数尚未达到maximumPoolSize,那么提升线程数。
  4. 此时仍未成功,那么触发reject。

我们可以在线上机器执行report时用jstack打印线程堆栈的方式来正式这一点。2018年3月22日15点的report由机器l-mail2.ter.prod.aws.dm完成,查看其堆栈:

得证。

阶段三

此阶段是report操作的核心所在,归纳为两步:

可以明显的看出,这是一个IO密集型操作。从目前日志来看,阶段三的耗时约1秒。

下面是其线程池的定义:

private static final int QUEUE_SIZE = 50000;
private static final ThreadPoolExecutor reportExecutor =
        new ThreadPoolExecutor(Runtime.getRuntime().availableProcessors(), Runtime.getRuntime().availableProcessors() * 2, 10L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<>(QUEUE_SIZE), ThreadUtils.newThreadFactoryByName("reportExecutor"));

这是一个有界队列(准确来说,int最大值也是有界…),仍以2018年3月22日l-mail2.ter.prod.aws.dm这次report为例,共有6万多report请求,所以我们可以推断,实际的工作线程数为8(核心数4):

同样得证。

但是,如果需要report的邮件数不足5万,那么实际工作的线程数便只有四个,以30607封为例,那么:

30607 / 4(线程数) / 1(秒) / 60 / 60 = 2.12小时

通过日志便可以印证此结论。进一步延伸,当邮件数超过5万(以51000为例),此时的耗时为:

51000 / 8 / 1 / 3600 = 1.77小时

反而比更少的邮件数时耗时低。

2、内存

这里重点关注老年代中的不可达对象,即垃圾。

 

可见,这里有大约300MB的由report线程池导致的垃圾,原因很容易想到:

每次report时都会有大量的MailReportRequest对象等待被处理。

3、昂贵的连接

我们服务请求mail gun使用的是HTTPS连接,众所周知,TCP连接的建立需要三次握手,断开需要四次挥手,是一个较重的操作。而HTTPS连接又加重了这一情形。但是:

我们的服务并未使用连接池(HTTP 1.1版本默认开始keep-alive,即连接复用),这就意味这每个时段的report需要执行5万次(约)TCP连接建立与HTTPS握手

无需测试,只需脑补即可想象这有多痛苦。

下面用debug的方法证明上述论断。使用MailGunMailVendor的getReports方法作为切入点,源码:

@Override
public List<MailReportResponse> getReports(MailReportEvent mailReportEvent) {
    WebResource webResource = client.resource(MAIL_EVENT_API);
 
    String responseBody = webResource.queryParams(queryParams).get(String.class);
 
    return mailReportResponses;
}

一路跟下去,核心点位于URLConnectionClientHandler的_invoke方法,如下图:

openConnection即JDK中URL类的方法,这就直接证明了我们上面的结论。所以,对昂贵的HTTPS连接进行复用是势在必行的。

4、并发更新

如果一封邮件mail gun有了状态变化,那么系统将拉取到的最新的状态更新到数据库中,按照原有的线程模型,有三个潜在的问题:

  1. 拉取report和更新状态为串行操作,无法充分利用多线程并发处理的优势。
  2. 单次更新按照主键进行,性能并不是问题,但是总体来看,会产生大量的小事物的提交。
  3. 每次与MySQL的交互均需要通过网络I/O完成。

所以,本次优化将其改为异步化、批量化。

三、优化

1、report线程池

提升report线程池的corePoolSize(比如改为40)即可,注意改pull线程池是没有作用的。

2、线程模型调整

消耗

每次report都会创建3万-6万的MailReportRequest对象、3万-6万的Runnable实现类对象(提交到线程池用)、3-6万的LinkedBlockingQueue的Node对象。我们来看看三种对象分别有多大。

MailReportRequest

com.vipkid.mail.MailReportRequest.limit @12 (int, 4b)
com.vipkid.mail.MailReportRequest.startTime @16 (java.lang.String, 4b)
com.vipkid.mail.MailReportRequest.endTime @20 (java.lang.String, 4b)
com.vipkid.mail.MailReportRequest.recipient @24 (java.lang.String, 4b)
com.vipkid.mail.MailReportRequest.from @28 (java.lang.String, 4b)
com.vipkid.mail.MailReportRequest.messageId @32 (java.lang.String, 4b)
size = 40

共40字节。

Runnable

size = 16

LinkedBlockingQueue$Node

外部无法访问其内部类Node,目测为4 + 4 + 8 = 16字节。

总结

简单计算一下,每天需要执行24 / 3 = 8次report,随机分配至3台机器,即每台机器每天执行约3次,故有:

40000(假设每次report邮件数) * 72B(每次邮件report消耗老年代大小) * 3(每台机器每天report次数) * 36(重启后到报警所需的天数) / 1024(KB) / 1024(MB) = 296.6MB

感觉和实际差不多。

新的线程模型

概括

总的来说,可以从下面两方面入手:

  1. 干掉pull线程池。此优化的意义不在于能够提升多少性能(或者说降低多少内存消耗),而是简化代码结构、线程模型。原因是将MailReportRequest提交到线程池其实是一个非常高效的操作,预计这里创建的Runnable对象可以在 Minor GC中就得到回收。
  2. 引入disruptor

示意图

图中report、更新DB的线程数只是一个示意。Disruptor是一个lock-free实现的高性能环形队列,当然这里引入disruptor的主要原因并不是其无锁特性(因为目前的处理速度锁应该还不是瓶颈),而是其事件对象预分配且固定

这就意味着上面提到的MailReportRequest、Runnable和Node不断堆积的问题便得到解决了。

3、连接池

我们服务使用的是1.9版本的jersey客户端,结合Apache HttpClient可以实现连接池的效果,这里参考:

Connection pooling using jersey client

Jersey Client 1.x Example

Q: Jersey如何处理连接关闭?

A: 既然有了”池”的概念,那么就不得不提资源的close/回收方法,我们下面来看看引入了连接池后jersey是在何时何地进行连接回收的。仍以下面请求代码为例:

String responseBody = webResource.queryParams(queryParams).get(String.class);

这里返回的是String类型,这很重要。跳过复杂的调用关系,核心位于org.apache.commons.httpclient.AutoCloseInputStream的close方法:

public void close() {
    if (!selfClosed) {
        selfClosed = true;
        notifyWatcher();
    }
}
notifyWatcher方法:
private void notifyWatcher() throws IOException {
    if (streamOpen) {
        super.close();
        streamOpen = false;
 
        if (watcher != null) {
            watcher.responseConsumed();
        }
    }
}

连接的回收最终就是在这里完成的。watcher在HttpMethodBase的readResponseBody方法中设置,部分源码:

private InputStream readResponseBody(HttpConnection conn){
    InputStream result = null;
    // if there is a result - ALWAYS wrap it in an observer which will
    // close the underlying stream as soon as it is consumed, and notify
    // the watcher that the stream has been consumed.
    if (result != null) {
        result = new AutoCloseInputStream(
            result,
            new ResponseConsumedWatcher() {
                public void responseConsumed() {
                    responseBodyConsumed();
                }
            }
        );
    }
    return result;
}

responseBodyConsumed方法最终会触发连接的回收。回收触发的时机便是当读取响应完成(遇到EOF)或显式调用close方法时

其中连接池参数设置参考了此篇文章,作者结合了在京东的实战经验,2333:

使用httpclient必须知道的参数设置及代码写法、存在的风险

本次新增的三个核心配置如下:

jersey.report.maxPoolSizePerHost=500
jersey.report.maxPoolSize=500
# milliseconds
jersey.connect.poolTimeout=500
jersey.send.maxPoolSize=200
jersey.send.maxPoolSizePerHost=200

这里maxPoolSizePerHost和maxPoolSize的取值相等,因为目前jersey只对mail gun一个host进行请求。除此之外,这里对发送和report连接池进行了隔离,防止大量的并发report对发送产生影响。

Q: Apache http client是如何检查连接是否有效的?

A: HttpConnection的closeIfStale方法:

public boolean closeIfStale() throws IOException {
    if (isOpen && isStale()) {
        LOG.debug("Connection is stale, closing...");
        close();
        return true;
    }
    return false;
}

核心逻辑位于isStale:

protected boolean isStale() throws IOException {
    boolean isStale = true;
    if (isOpen) {
        // the connection is open, but now we have to see if we can read it
        // assume the connection is not stale.
        isStale = false;
        try {
            if (inputStream.available() <= 0) {
                try {
                    socket.setSoTimeout(1);
                    inputStream.mark(1);
                    int byteRead = inputStream.read();
                    if (byteRead == -1) {
                        // again - if the socket is reporting all data read,
                        // probably stale
                        isStale = true;
                    else {
                        inputStream.reset();
                    }
                finally {
                    socket.setSoTimeout(this.params.getSoTimeout());
                }
            }
        catch (InterruptedIOException e) {
            if (!ExceptionUtil.isSocketTimeoutException(e)) {
                throw e;
            }
            // aha - the connection is NOT stale - continue on!
        catch (IOException e) {
            // oops - the connection is stale, the read or soTimeout failed.
            LOG.debug(
                "An error occurred while reading from the socket, is appears to be stale",
                e
            );
            isStale = true;
        }
    }
 
    return isStale;
}

总结为:

  1. 判断(inputStream.available() <= 0)的目的是支持BufferedInputStream,如果此时连接已经断开但是buffer中尚有未处理的数据,仍然认为是有效的。
  2. 核心的检查逻辑是首先设置一个较短的超时时间,然后执行读操作,如果返回-1,那么说明已断开,如果抛出超时异常(SocketTimeoutException),那么我们依然认为是有效的
  3. 如果抛出其它异常(非SocketTimeoutException),那么认为已断开。

其实这样的判断逻辑依然有问题,即如果网络断开,那么此方法依然会认为是有效的。真正可以准确判断TCP连接断开的方式是write,而不是read,但是精确的判断需要一个较长的耗时(甚至可以达到15分钟)。所以,此种判断方式其实是在准确性和性能之间做了一个折中与取舍。

Q: 服务器是否开启了keep-alive支持?

A: 首先,mail gun服务使用的是HTTP 1.1协议,而此协议默认是开启了keep-alive,我们直接使用curl工具打印一下请求report的响应头,命令:

curl -i -s --user 'api:key-5f57bf6ed1fe62dfed144e551c60b07f' -G \
      https://api.mailgun.net/v3/vipkid.net/events \
      --data-urlencode begin='Fri, 3 May 2013 09:00:00 -0000' \
      --data-urlencode ascending=yes \
      --data-urlencode limit=25 \
      --data-urlencode pretty=yes \
      --data-urlencode recipient=zhangpeilei@vipkid.com.cn \
      --data-urlencode message-id=20180410103836.1.A1CC5A23FBE20FF4@vipkid.net

响应头如下所示:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type, x-requested-with
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 600
Content-Type: application/json
Date: Wed, 11 Apr 2018 03:32:21 GMT
Content-Length: 5107
Server: nginx
Connection: keep-alive

注意最后两行,说明mail gun的服务器是nginx且支持keep-alive,但是这里还是有一个隐藏的问题,即:mail gun的nginx设置的超时时间是多少?

此参数由配置keepalive_timeout决定,默认为75秒,设置为0即关闭keep-alive,所以我们的连接池中的连接可以复用多久取决于mail gun的配置。

如果在nginx中配置为:

http {
    keepalive_timeout  0;
}

那么响应头其实是这样的:

对比一下大于零时:

即可进一步得出结论:我们虽然不知道mail gun服务器设置的keep-alive超时时间是多少,但是可以肯定必定大于零

另外,nginx除了对连接有时间上的限制外,还在一个连接处理的请求数维度上进行了限制,来自官方文档:

下面从WireShark的角度确认连接池确实已生效,测试的方法为对两封邮件进行report,注意应该先将连接池的最大连接数设置为1,否则看不到效果,如下:

非常和谐的结果,一次握手,两次交互。

与之对比,使用相同的数据、原来的代码进行测试,如下:

明显的两次握手,两次交互,证明我们的连接池是确实生效的。

Q: HTTP的keep-alive和TCP的keep alive什么区别?

A: Google, Baidu…

4、异步更新

如上面线程模型图,初步设置的批量更新的批次大小为100。这里有个问题,100条是否过大会导致执行失败?

首先MySQL似乎并没有对这个批量的条数有明确的限制,摘自官方文档:

所以唯一的限制应该是喜闻乐见的max_allowed_packet参数,即每次与MySQL服务器交互最大的包大小。可以在nods平台执行以下语句查看其取值:

show VARIABLES like '%max_allowed_packet%';

线上的执行结果如下图:

即128MB。这是MySQL服务器的设置,在jdbc驱动层面上同样可以对此参数进行设置,以下是官方文档:

由于在jdbc层面上我们没有对此参数进行设置,所以最终的上限就是64MB。

一个典型的update语句如下:

UPDATE mail_reports SET status = 1, content = '[{"recipient":"hasekiue@hotmail.com","event":"delivered","timestamp":"1.522422415268628E9","result":1},{"recipient":"hasekiue@hotmail.com","event":"accepted","timestamp":"1.522422414412456E9","result":0}]' WHERE id = 98842348;

长度为273B,所以100条的长度为:273B * 100 / 1024 = 27KB,可以得出最终结论:

100条update语句的大小远小于单次交互字节数上限,不必担心

5、参数调整

-Xms4608M -Xmx4608M -XX:MaxDirectMemorySize=200M -XX:NewRatio=2

思路:

  1. 降低整个堆的大小,内存报警很大程度是由于配置不合理导致,堆内存 + Metaspace等空间 + 其它程序占用内存早已超过物理内存。
  2. 限制堆外内存(NIO用)大小,默认情况下为堆内存减去一个Survivor,虽然在目前的业务场景下堆外内存不会大量使用,但仍然是一个隐患。
  3. 在降低堆的总大小的前提下保持新生代大小不变:4608M / 3 == 6144M / 4.

同时按照如下公式:

4608MB * 70%(CMS回收阈值) + 0.5GB(Metaspace) + 0.5GB(CompressedClassSpaceSize) + 1GB(机器上的其它进程(比如:日志收集进程)) + 0.2GB(Direct buffer) = 5.35GB

而:

5.35GB / 7GB = 76%

未达到报警阈值的80%,所以这样也不会导致内存报警。

Q: NIO用的direct buffer默认上限是多大?

A: 堆内存上限(Xmx)减去一个survivor,非常恐怖。

四、不可描述

  1. 邮件服务从启动到开始报警,没有一次Full GC,也就是说,直到报警,堆的占用率也未达到CMS垃圾回收的阈值 从上图可以看出,堆的最大占用率为59.6%,而我们设置的CMS垃圾回收阈值是70%.
  2. 目前线上Minor GC的频率约为3分钟一次。
  3. 内存暴涨和report之间的关系: 以mail2的GC日志server-gc.log.201804120649为例,内存增长曲线图: 明显有几个暴涨的时间点,这里的时间点是一个相对值(相对于启动时间),结合系统在2018年4月12号早晨6点49启动,所以可以大体推断出绝对值。通过日志查看下mail2机器report执行情况: 后两次report与启动时间的相对值分别为8和14,大体和前两个暴涨的时间点吻合,所以这似乎可以说明report对老年代的增长起到了很大的作用。

五、参考

  1. Shallow heap & Retained heap
  2. LMAX Disruptor
  3. 高性能队列——Disruptor
  4. 新生代和老年代怎样的比例比较合适
  5. JVM源码分析之Metaspace解密
  6. MySQL 加锁处理分析
  7. connector-j-reference-configuration-properties
  8. packet-too-large
  9. [HotSpot VM] JVM调优的”标准参数”的各种陷阱
  10. keepalive_timeout
  11. TCP keepalive 和 http keep-alive

六、附件

server-gc.log.201804120649

消息“时序”与“一致性”为何这么难?

分布式系统中,很多业务场景都需要考虑消息投递的时序,例如:

(1)单聊消息投递,保证发送方发送顺序与接收方展现顺序一致

(2)群聊消息投递,保证所有接收方展现顺序一致

(3)充值支付消息,保证同一个用户发起的请求在服务端执行序列一致

消息时序是分布式系统架构设计中非常难的问题,ta为什么难,有什么常见优化实践,是本文要讨论的问题。

 

一、为什么时序难以保证,消息一致性难?

为什么分布式环境下,消息的时序难以保证,这边简要分析了几点原因:

【时钟不一致】


分布式环境下,有多个客户端、有web集群、service集群、db集群,他们都分布在不同的机器上,机器之间都是使用的本地时钟,而没有一个所谓的“全局时钟”,所以不能用“本地时间”来完全决定消息的时序

 

【多客户端(发送方)】


多服务器不能用“本地时间”进行比较,假设只有一个接收方,能否用接收方本地时间表示时序呢?遗憾的是,由于多个客户端的存在,即使是一台服务器的本地时间,也无法表示“绝对时序”

如上图,绝对时序上,APP1先发出msg1,APP2后发出msg2,都发往服务器web1,网络传输是不能保证msg1一定先于msg2到达的,所以即使以一台服务器web1的时间为准,也不能精准描述msg1与msg2的绝对时序。

 

【服务集群(多接收方)】


多发送方不能保证时序,假设只有一个发送方,能否用发送方的本地时间表示时序呢?遗憾的是,由于多个接收方的存在,无法用发送方的本地时间,表示“绝对时序”

如上图,绝对时序上,web1先发出msg1,后发出msg2,由于网络传输及多接收方的存在,无法保证msg1先被接收到先被处理,故也无法保证msg1与msg2的处理时序。

 

【网络传输与多线程】


多发送方与多接收方都难以保证绝对时序,假设只有单一的发送方与单一的接收方,能否保证消息的绝对时序呢?结论是悲观的,由于网络传输与多线程的存在,仍然不行。

如上图,web1先发出msg1,后发出msg2,即使msg1先到达(网络传输其实还不能保证msg1先到达),由于多线程的存在,也不能保证msg1先被处理完。

 

【怎么保证绝对时序】

通过上面的分析,假设只有一个发送方,一个接收方,上下游连接只有一条连接池,通过阻塞的方式通讯,难道不能保证先发出的消息msg1先处理么?

回答:可以,但吞吐量会非常低,而且单发送方单接收方单连接池的假设不太成立,高并发高可用的架构不会允许这样的设计出现

 

二、优化实践

【以客户端或者服务端的时序为准】

多客户端、多服务端导致“时序”的标准难以界定,需要一个标尺来衡量时序的先后顺序,可以根据业务场景,以客户端或者服务端的时间为准,例如:

(1)邮件展示顺序,其实是以客户端发送时间为准的,潜台词是,发送方只要将邮件协议里的时间调整为1970年或者2970年,就可以在接收方收到邮件后一直“置顶”或者“置底”

(2)秒杀活动时间判断,肯定得以服务器的时间为准,不可能让客户端修改本地时间,就能够提前秒杀

 

【服务端能够生成单调递增的id】

这个是毋庸置疑的,不展开讨论,例如利用单点写db的seq/auto_inc_id肯定能生成单调递增的id,只是说性能及扩展性会成为潜在瓶颈。对于严格时序的业务场景,可以利用服务器的单调递增id来保证时序。

 

【大部分业务能接受误差不大的趋势递增id】

消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求:

(1)同1s内发布的聊天消息时序乱了

(2)同1s内发布的帖子排序不对

(3)用1s内发起的秒杀,由于服务器多台之间时间有误差,落到A服务器的秒杀成功了,落到B服务器的秒杀还没开始,业务上也是可以接受的(用户感知不到)

所以,大部分业务,长时间趋势递增的时序就能够满足业务需求,非常短时间的时序误差一定程度上能够接受。

关于绝对递增id,趋势递增id的生成架构,详见文章《细聊分布式ID生成方法》,此处不展开。

 

【利用单点序列化,可以保证多机相同时序】

数据为了保证高可用,需要做到进行数据冗余,同一份数据存储在多个地方,怎么保证这些数据的修改消息是一致的呢?利用的就是“单点序列化”:

(1)先在一台机器上序列化操作

(2)再将操作序列分发到所有的机器,以保证多机的操作序列是一致的,最终数据是一致的

 

典型场景一:数据库主从同步


数据库的主从架构,上游分别发起了op1,op2,op3三个操作,主库master来序列化所有的SQL写操作op3,op1,op2,然后把相同的序列发送给从库slave执行,以保证所有数据库数据的一致性,就是利用“单点序列化”这个思路。

 

典型场景二:GFS中文件的一致性


GFS(Google File System)为了保证文件的可用性,一份文件要存储多份,在多个上游对同一个文件进行写操作时,也是由一个主chunk-server先序列化写操作,再将序列化后的操作发送给其他chunk-server,来保证冗余文件的数据一致性的。

 

【单对单聊天,怎么保证发送顺序与接收顺序一致】

单人聊天的需求,发送方A依次发出了msg1,msg2,msg3三个消息给接收方B,这三条消息能否保证显示时序的一致性(发送与显示的顺序一致)?

回答:

(1)如果利用服务器单点序列化时序,可能出现服务端收到消息的时序为msg3,msg1,msg2,与发出序列不一致

(2)业务上不需要全局消息一致,只需要对于同一个发送方A,ta发给B的消息时序一致就行,常见优化方案,在A往B发出的消息中,加上发送方A本地的一个绝对时序,来表示接收方B的展现时序

msg1{seq:10, receiver:B,msg:content1 }

msg2{seq:20, receiver:B,msg:content2 }

msg3{seq:30, receiver:B,msg:content3 }


潜在问题:如果接收方B先收到msg3,msg3会先展现,后收到msg1和msg2后,会展现在msg3的前面。

无论如何,是按照接收方收到时序展现,还是按照服务端收到的时序展现,还是按照发送方发送时序展现,是pm需要思考的点,技术上都能够实现(接收方按照发送时序展现是更合理的)。

总之,需要一杆标尺来衡量这个时序。

 

【群聊消息,怎么保证各接收方收到顺序一致】

群聊消息的需求,N个群友在一个群里聊,怎么保证所有群友收到的消息显示时序一致?

回答:

(1)不能再利用发送方的seq来保证时序,因为发送方不单点,时间也不一致

(2)可以利用服务器的单点做序列化


此时群聊的发送流程为:

(1)sender1发出msg1,sender2发出msg2

(2)msg1和msg2经过接入集群,服务集群

(3)service层到底层拿一个唯一seq,来确定接收方展示时序

(4)service拿到msg2的seq是20,msg1的seq是30

(5)通过投递服务讲消息给多个群友,群友即使接收到msg1和msg2的时间不同,但可以统一按照seq来展现

这个方法能实现,所有群友的消息展示时序相同。

缺点是,这个生成全局递增序列号的服务很容易成为系统瓶颈,还有没有进一步的优化方法呢

 

思路:群消息其实也不用保证全局消息序列有序,而只要保证一个群内的消息有序即可,这样的话,“id串行化”就成了一个很好的思路。


这个方案中,service层不再需要去一个统一的后端拿全局seq,而是在service连接池层面做细小的改造,保证一个群的消息落在同一个service上,这个service就可以用本地seq来序列化同一个群的所有消息,保证所有群友看到消息的时序是相同的。

关于id串行化的细节,可详见《利用id串行化解决缓存与数据库一致性问题》,此处不展开。

 

三、总结

(1)分布式环境下,消息的有序性是很难的,原因多种多样:时钟不一致,多发送方,多接收方,多线程,网络传输不确定性等

(2)要“有序”,先得有衡量“有序”的标尺,可以是客户端标尺,可以是服务端标尺

(3)大部分业务能够接受大范围趋势有序,小范围误差;绝对有序的业务,可以借助服务器绝对时序的能力

(4)单点序列化,是一种常见的保证多机时序统一的方法,典型场景有db主从一致,gfs多文件一致

(5)单对单聊天,只需保证发出的时序与接收的时序一致,可以利用客户端seq

(6)群聊,只需保证所有接收方消息时序一致,需要利用服务端seq,方法有两种,一种单点绝对时序,另一种id串行化

转自:http://mp.weixin.qq.com/s/_853zUkO9uPnirHzCQoVyw

MySQL 死锁问题分析

线上某服务时不时报出如下异常(大约一天二十多次):“Deadlock found when trying to get lock;”。

Oh, My God! 是死锁问题。尽管报错不多,对性能目前看来也无太大影响,但还是需要解决,保不齐哪天成为性能瓶颈。
为了更系统的分析问题,本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。

图1 应用日志

1 死锁是怎么被发现的?

1.1 死锁成因&&检测方法

左图那两辆车造成死锁了吗?不是!右图四辆车造成死锁了吗?是!

图2 死锁描述

我们mysql用的存储引擎是innodb,从日志来看,innodb主动探知到死锁,并回滚了某一苦苦等待的事务。问题来了,innodb是怎么探知死锁的?直观方法是在两个事务相互等待时,当一个等待时间超过设置的某一阀值时,对其中一个事务进行回滚,另一个事务就能继续执行。这种方法简单有效,在innodb中,参数innodb_lock_wait_timeout用来设置超时时间。

仅用上述方法来检测死锁太过被动,innodb还提供了wait-for graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for graph算法都会被触发。

1.2 wait-for graph原理

我们怎么知道上图中四辆车是死锁的?他们相互等待对方的资源,而且形成环路!我们将每辆车看为一个节点,当节点1需要等待节点2的资源时,就生成一条有向边指向节点2,最后形成一个有向图。我们只要检测这个有向图是否出现环路即可,出现环路就是死锁!这就是wait-for graph算法。

图3 wait for graph

innodb将各个事务看为一个个节点,资源就是各个事务占用的锁,当事务1需要等待事务2的锁时,就生成一条有向边从1指向2,最后行成一个有向图。

1.2 innodb隔离级别、索引与锁

死锁检测是死锁发生时innodb给我们的救命稻草,我们需要它,但我们更需要的是避免死锁发生的能力,如何尽可能避免?这需要了解innodb中的锁。

1.2.1 锁与索引的关系

假设我们有一张消息表(msg),里面有3个字段。假设id是主键,token是非唯一索引,message没有索引。

id: bigint token: varchar(30) message: varchar(4096)

innodb对于主键使用了聚簇索引,这是一种数据存储方式,表数据是和主键一起存储,主键索引的叶结点存储行数据。对于普通索引,其叶子节点存储的是主键值。

图4 聚簇索引和二级索引

下面分析下索引和锁的关系。
1)delete from msg where id=2;

由于id是主键,因此直接锁住整行记录即可。

图5

2)delete from msg where token=’ cvs’;

由于token是二级索引,因此首先锁住二级索引(两行),接着会锁住相应主键所对应的记录;

图6

3)delete from msg where message=订单号是多少’;

message没有索引,所以走的是全表扫描过滤。这时表上的各个记录都将添加上X锁。

图7

1.2.2 锁与隔离级别的关系

大学数据库原理都学过,为了保证并发操作数据的正确性,数据库都会有事务隔离级别的概念:1)未提交读(Read uncommitted);2)已提交读(Read committed(RC));3)可重复读(Repeatable read(RR));4)可串行化(Serializable)。我们较常使用的是RC和RR。

提交读(RC):只能读取到已经提交的数据。

可重复读(RR):在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。

我们在1.2.1节谈论的其实是RC隔离级别下的锁,它可以防止不同事务版本的数据修改提交时造成数据冲突的情况,但当别的事务插入数据时可能会出现问题。

如下图所示,事务A在第一次查询时得到1条记录,在第二次执行相同查询时却得到两条记录。从事务A角度上看是见鬼了!这就是幻读,RC级别下尽管加了行锁,但还是避免不了幻读。

图8

innodb的RR隔离级别可以避免幻读发生,怎么实现?当然需要借助于锁了!

为了解决幻读问题,innodb引入了gap锁。

在事务A执行:update msg set message=‘订单’ where token=‘asd’;

innodb首先会和RC级别一样,给索引上的记录添加上X锁,此外,还在非唯一索引’asd’与相邻两个索引的区间加上锁。

这样,当事务B在执行insert into msg values (null,‘asd’,’hello’); commit;时,会首先检查这个区间是否被锁上,如果被锁上,则不能立即执行,需要等待该gap锁被释放。这样就能避免幻读问题。

图9

3 死锁成因

了解了innodb锁的基本原理后,下面分析下死锁的成因。如前面所说,死锁一般是事务相互等待对方资源,最后形成环路造成的。下面简单讲下造成相互等待最后形成环路的例子。

3.1不同表相同记录行锁冲突

这种情况很好理解,事务A和事务B操作两张表,但出现循环等待锁情况。

图10

3.2相同表记录行锁冲突

这种情况比较常见,之前遇到两个job在执行数据批量更新时,jobA处理的的id列表为[1,2,3,4],而job处理的id列表为[8,9,10,4,2],这样就造成了死锁。


图11

3.3不同索引锁冲突

这种情况比较隐晦,事务A在执行时,除了在二级索引加锁外,还会在聚簇索引上加锁,在聚簇索引上加锁的顺序是[1,4,2,3,5],而事务B执行时,只在聚簇索引上加锁,加锁顺序是[1,2,3,4,5],这样就造成了死锁的可能性。

图12

3.4 gap锁冲突

innodb在RR级别下,如下的情况也会产生死锁,比较隐晦。不清楚的同学可以自行根据上节的gap锁原理分析下。

图13

4 如何尽可能避免死锁

1)以固定的顺序访问表和行。比如对第2节两个job批量更新的情形,简单方法是对id列表先排序,后执行,这样就避免了交叉等待锁的情形;又比如对于3.1节的情形,将两个事务的sql顺序调整为一致,也能避免死锁。

2)大事务拆小。大事务更倾向于死锁,如果业务允许,将大事务拆小。

3)在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率。

4)降低隔离级别。如果业务允许,将隔离级别调低也是较好的选择,比如将隔离级别从RR调整为RC,可以避免掉很多因为gap锁造成的死锁。

5)为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁,死锁的概率大大增大。

5 如何定位死锁成因

下面以本文开头的死锁案例为例,讲下如何排查死锁成因。

1)通过应用业务日志定位到问题代码,找到相应的事务对应的sql;

因为死锁被检测到后会回滚,这些信息都会以异常反应在应用的业务日志中,通过这些日志我们可以定位到相应的代码,并把事务的sql给梳理出来。

start tran

1 deleteHeartCheckDOByToken

2 updateSessionUser

commit

此外,我们根据日志回滚的信息发现在检测出死锁时这个事务被回滚。

2)确定数据库隔离级别。

执行select @@global.tx_isolation,可以确定数据库的隔离级别,我们数据库的隔离级别是RC,这样可以很大概率排除gap锁造成死锁的嫌疑;

3)找DBA执行下show InnoDB STATUS看看最近死锁的日志。

这个步骤非常关键。通过DBA的帮忙,我们可以有更为详细的死锁信息。通过此详细日志一看就能发现,与之前事务相冲突的事务结构如下:

start tran

1 updateSessionUser

2 deleteHeartCheckDOByToken

commit

这不就是图10描述的死锁嘛!

转自:http://mp.weixin.qq.com/s/u_T8dDrEKaqQtW8TE4rXIQ