关注服务器架构设计
关注互联网

[转]并发编程:Actors模型和CSP模型

NickYang阅读(275)评论(3)

一、前言

不同的编程模型与具体的语言无关,大部分现代语言都可以通过巧妙地结构处理实现不同的模型.杂谈的意思是很杂,想到哪儿写到哪儿,不对正确性负责 :D.

 

二、Actors模型

传统的并发模型主要由两种实现的形式,一是同一个进程下,多个线程天然的共享内存,由程序对读写做同步控制(有锁或无锁). 二是多个进程通过进程间通讯或者内存映射实现数据的同步.

Actors模型更多的使用消息机制来实现并发,目标是让开发者不再考虑线程这种东西,每个Actor最多同时只能进行一样工作,Actor内部可以有自己的变量和数据.

Actors模型避免了由操作系统进行任务调度的问题,在操作系统进程之上,多个Actor可能运行在同一个进程(或线程)中.这就节省了大量的Context切换.

在Actors模型中,每个Actor都有一个专属的命名”邮箱”, 其他Actor可以随时选择一个Actor通过邮箱收发数据,对于“邮箱”的维护,通常是使用发布订阅的机制实现的,比如我们可以定义发布者是自己,订阅者可以是某个Socket接口,另外的消息总线或者直接是目标Actor.

目前akka库是比较流行的Actors编程模型实现,支持Scala和Java语言.

 

三、CSP模型

CSP(Communicating Sequential Process)模型提供一种多个进程公用的“管道(channel)”, 这个channel中存放的是一个个”任务”.

目前正流行的go语言中的goroutine就是参考的CSP模型,原始的CSP中channel里的任务都是立即执行的,而go语言为其增加了一个缓存,即任务可以先暂存起来,等待执行进程准备好了再逐个按顺序执行.

 

四、CSP和Actor的区别

  • CSP进程通常是同步的(即任务被推送进Channel就立即执行,如果任务执行的线程正忙,则发送者就暂时无法推送新任务),Actor进程通常是异步的(消息传递给Actor后并不一定马上执行).
  • CSP中的Channel通常是匿名的, 即任务放进Channel之后你并不需要知道是哪个Channel在执行任务,而Actor是有“身份”的,你可以明确的知道哪个Actor在执行任务.
  • 在CSP中,我们只能通过Channel在任务间传递消息, 在Actor中我们可以直接从一个Actor往另一个Actor传输数据.
  • CSP中消息的交互是同步的,Actor中支持异步的消息交互.

 

五、参考文档

文章转载自:http://sobuhu.com/program/2014/09/07/concurrent-models.html

(更多…)

ArkGameFrame实战系列文章说明

NickYang阅读(566)评论(0)

ArkGameFrame是一个面向中小型企业的开源游戏服务器敏捷开发框架,继承自NFrame,主要是项目的管理方式不同,这块经过沟通,很难有一个大家都满意的结果,所以暂时新作一个组织结构来管理这几个项目,后面再看结果是否合并。

关于这个框架的设计过程的介绍文章,请查看NF博客

前面我们已经通过一系列ArkGameFrame架构和设计的文章来说明Ark是如何设计的,以及里面用到了什么技术,相信大家已经对Ark有了一个比较全面的了解了。

不过俗话说:光说不练假把式,光练不说傻把式,下面我们会通过一系列游戏开发实战文章来逐步介绍如何通过Ark框架实现一个较完整的游戏服务器。

大致的文章如下:

文章中的内容实现将会在ArkGameServer中实现,我们还在努力做服务器业务内容的开发。

如果大家对于Ark实战开发还有什么需求,可以在QQ群(341159815)里提出来,我们后续再补充进去。

[转]高并发性能调试经验分享

NickYang阅读(783)评论(0)

作者:helloworlds
链接:https://zhuanlan.zhihu.com/p/21348220
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

引文

4月份的时候看到一道面试题,据说是腾讯校招面试官提的:在多线程和高并发环境下,如果有一个平均运行一百万次才出现一次的bug,你如何调试这个bug?知乎原贴地址如下:腾讯实习生面试,这两道题目该怎么回答? – 编程 .
遗憾的是知乎很多答案在抨击这道题本身的正确性,虽然我不是这次的面试官,但我认为这是一道非常好的面试题。当然,只是道加分题,答不上,不扣分。答得不错,说明解决问题的思路和能力要超过应届生平均水平。
之所以写上面这段,是因为我觉得大部分后台服务端开发都有可能遇到这样的BUG,即使没有遇到,这样的题目也能够激发大家不断思考和总结。非常凑巧的是,我在4月份也遇到了一个类似的而且要更加严重的BUG,这是我自己挖的一个很深的坑,不填好,整个项目就无法上线。
现在已经过去了一个多月,趁着有时间,自己好好总结一下,希望里面提到的一些经验和工具能够带给大家一点帮助。

项目背景

我们针对nginx事件框架和openssl协议栈进行了一些深度改造,以提升nginx的HTTPS完全握手计算性能。
由于原生nginx使用本地CPU做RSA计算,ECDHE_RSA算法的单核处理能力只有400 qps左右。前期测试时的并发性能很低,就算开了24核,性能也无法超过1万。
核心功能在去年底就完成了开发,线下测试也没有发现问题。经过优化后的性能提升几倍,为了测试最大性能,使用了很多客户端并发测试https性能。很快就遇到了一些问题:

  1. 第一个问题是nginx有极低概率(亿分之一)在不同地方 core dump。白天线下压力测试2W qps一般都要两三个小时才出一次core。每次晚上睡觉之前都会将最新的调试代码编译好并启动测试,到早上醒来第一眼就会去查看机器并祈祷不要出core,不幸的是,一般都会有几个到几十个core,并且会发现经常是在一个时间点集中core dump。线上灰度测试运行了6天,在第6天的早上才集中core dump了几十次。这样算来,这个core dump的概率至少是亿分之一了。 不过和面试题目中多线程不同的是,nginx采用的是多进程+全异步事件驱动的编程模式(目前也支持了多线程,但只是针对IO的优化,核心机制还是多进程加异步)。在webserver的实现背景下,多进程异步相比多线程的优点是性能高,没有太多线程间的切换,而且内存空间独立,省去线程间锁的竞争。当然也有缺点,就是异步模式编程非常复杂,将一些逻辑上连续的事件从空间和时间切割,不符合人的正常思考习惯,出了问题后比较难追查。另外异步事件对网络和操作系统的底层知识要求较高,稍不小心就容易挖坑。
  2. 第二个问题是高并发时nginx存在内存泄漏。在流量低的时候没有问题,加大测试流量就会出现内存泄漏。
  3. 第三个问题,因为我们对nginx和openssl的关键代码都做了一些改造,希望提升它的性能。那么如何找到性能热点和瓶颈并持续优化呢?

其中第一和第二个问题的背景都是,只有并发上万qps以上时才有可能出现,几百或者一两千QPS时,程序没有任何问题。

core dump的调试

首先说一下core的解决思路,主要是如下几点:

  1. gdb及debug log定位,发现作用不大。
  2. 如何重现bug?
  3. 构造高并发压力测试系统。
  4. 构造稳定的异常请求。

gdb及debug log效率太低

因为有core dump ,所以这个问题初看很容易定位。gdb 找到core dump点,btrace就能知道基本的原因和上下文了。
core的直接原因非常简单和常见,全部都是NULL指针引用导致的。不过从函数上下文想不通为什么会出现NULL值,因为这些指针在原生nginx的事件和模块中都是这么使用的,不应该在这些地方变成NULL。由于暂时找不到根本原因,还是先解决CORE dump吧,修复办法也非常简单,直接判断指针是否NULL,如果是NULL就直接返回,不引用不就完事了,这个地方以后肯定不会出CORE了。

这样的防守式编程并不提倡,指针NULL引用如果不core dump,而是直接返回,那么这个错误很有可能会影响用户的访问,同时这样的BUG还不知道什么时候能暴露。所以CORE DUMP 在NULL处,其实是非常负责任和有效的做法。

在NULL处返回,确实避免了在这个地方的CORE,但是过几个小时又core 在了另外一个NULL指针引用上。于是我又继续加个判断并避免NULL指针的引用。悲剧的是,过了几个小时,又CORE在了其他地方,就这样过了几天,我一直在想为什么会出现一些指针为NULL的情况?为什么会CORE在不同地方?为什么我用浏览器和curl这样的命令工具访问却没有任何问题?

熟悉nginx代码的同学应该很清楚,nginx极少在函数入口及其他地方判断指针是否为NULL值。特别是一些关键数据结构,比如‘ngx_connection_t’及SSL_CTX等,在请求接收的时候就完成了初始化,所以不可能在后续正常处理过程中出现NULL的情况。

于是我更加迷惑,显然NULL值导致出CORE只是表象,真正的问题是,这些关键指针为什么会被赋值成NULL?
这个时候异步事件编程的缺点和复杂性就暴露了,好好的一个客户端的请求,从逻辑上应该是连续的,但是被读写及时间事件拆成了多个片断。虽然GDB能准确地记录core dump时的函数调用栈,但是却无法准确记录一条请求完整的事件处理栈。根本就不知道上次是哪个事件的哪些函数将这个指针赋值为NULL的,甚至都不知道这些数据结构上次被哪个事件使用了。

举个例子:客户端发送一个正常的get请求,由于网络或者客户端行为,需要发送两次才完成。服务端第一次read没有读取完全部数据,这次读事件中调用了 A,B函数,然后事件返回。第二次数据来临时,再次触发read事件,调用了A,C函数。并且core dump在了C函数中。这个时候,btrace的stack frame已经没有B函数调用的信息了。

所以通过GDB无法准确定位 core 的真正原因

log debug的新尝试
这时候强大的GDB已经派不上用场了。怎么办?打印nginx调试日志。
但是打印日志也很郁闷,只要将nginx的日志级别调整到DEBUG,CORE就无法重现。为什么?因为DEBUG的日志信息量非常大,频繁地写磁盘严重影响了NGINX的性能,打开DEBUG后性能由几十万直线下降到几百qps。
调整到其他级别比如 INFO,性能虽然好了,但是日志信息量太少,没有帮助。尽管如此,日志却是个很好的工具,于是又尝试过以下办法:

  1. 针对特定客户端IP开启debug日志,比如IP是10.1.1.1就打印DEBUG,其他IP就打印最高级别的日志,nginx本身就支持这样的配置。
  2. 关闭DEBUG日志,自己在一些关键路径添加高级别的调试日志,将调试信息通过EMERG级别打印出来。
  3. nginx只开启一个进程和少量的connection数。抽样打印连接编号(比如尾号是1)的调试日志。

总体思路依然是在不明显降低性能的前提下打印尽量详细的调试日志,遗憾的是,上述办法还是不能帮助问题定位,当然了,在不断的日志调试中,对代码和逻辑越来越熟悉。

bug如何重现?

这时候的调试效率已经很低了,几万QPS连续压力测试,几个小时才出一次CORE,然后修改代码,添加调试日志。几天过去了,毫无进展。所以必须要在线下构造出稳定的core dump环境,这样才能加快debug效率。
虽然还没有发现根本原因,但是发现了一个很可疑的地方:
出CORE比较集中,经常是在凌晨4,5点,早上7,8点的时候 dump几十个CORE。

弱网络环境的构造 traffic control

联想到夜间有很多的网络硬件调整及故障,我猜测这些core dump可能跟网络质量相关。**特别是网络瞬时不稳定,很容易触发BUG导致大量的CORE DUMP。**
最开始我考虑过使用TC(traffic control)工具来构造弱网络环境,但是转念一想,弱网络环境导致的结果是什么?显然是网络请求的各种异常啊,所以还不如直接构造各种异常请求来复现问题。于是准备构造测试工具和环境,需要满足两个条件:

  1. 并发性能强,能够同时发送数万甚至数十万级以上qps。
  2. 请求需要一定概率的异常。特别是TCP握手及SSL握手阶段,需要异常中止。

traffic control是一个很好的构造弱网络环境的工具,我之前用过测试SPDY协议性能。能够控制网络速率、丢包率、延时等网络环境,作为iproute工具集中的一个工具,由linux系统自带。但比较麻烦的是TC的配置规则很复杂,facebook在tc的基础上封装成了一个开源工具apc,有兴趣的可以试试。

WRK压力测试工具

由于高并发流量时才可能出core,所以首先就需要找一个性能强大的压测工具。
WRK是一款非常优秀的开源HTTP压力测试工具,采用多线程 + 异步事件驱动的框架,其中事件机制使用了redis的ae事件框架,协议解析使用了nginx的相关代码。
相比ab(apache bench)等传统压力测试工具的优点就是性能好,基本上单台机器发送几百万pqs,打满网卡都没有问题。
wrk的缺点就是只支持HTTP类协议,不支持其他协议类测试,比如protobuf,另外数据显示也不是很方便。

nginx的测试用法: wrk -t500 -c2000 -d30s 127.0.0.1:8443/index.ht

分布式自动测试系统的构建

由于是HTTPS请求,使用ECDHE_RSA密钥交换算法时,客户端的计算消耗也比较大,单机也就10000多qps。也就是说如果server的性能有3W qps,那么一台客户端是无法发送这么大的压力的,所以需要构建一个多机的分布式测试系统,即通过中控机同时控制多台测试机客户端启动和停止测试。
之前也提到了,调试效率太低,整个测试过程需要能够自动化运行,比如晚上睡觉前,可以控制多台机器在不同的协议,不同的端口,不同的cipher suite运行整个晚上。白天因为一直在盯着,运行几分钟就需要查看结果。
这个系统有如下功能:
1. 并发控制多台测试客户端的启停,最后汇总输出总的测试结果。
2. 支持https,http协议测试,支持webserver及revers proxy性能测试。
3. 支持配置不同的测试时间、端口、URL。
4. 根据端口选择不同的SSL协议版本,不同的cipher suite。
5. 根据URL选择webserver、revers proxy模式。

异常测试请求的构造

压力测试工具和系统都准备好了,还是不能准确复现core dump的环境。接下来还要完成异常请求的构造。构造哪些异常请求呢?
由于新增的功能代码主要是和SSL握手相关,这个过程是紧接着TCP握手发生的,所以异常也主要发生在这个阶段。于是我考虑构造了如下三种异常情形:

  1. 异常的tcp连接。即在客户端tcp connent系统调用时,10%概率直接close这个socket。
  2. 异常的ssl连接。考虑两种情况,full handshake第一阶段时,即发送 client hello时,客户端10%概率直接close连接。full handshake第二阶段时,即发送clientKeyExchange时,客户端10%概率直接直接关闭TCP连接。
  3. 异常的HTTPS请求,客户端10%的请求使用错误的公钥加密数据,这样nginx解密时肯定会失败。

core bug fix小结

构造好了上述高并发压力异常测试系统,果然,几秒钟之内必然出CORE。有了稳定的测试环境,那bug fix的效率自然就会快很多。
虽然此时通过gdb还是不方便定位根本原因,但是测试请求已经满足了触发CORE的条件,打开debug调试日志也能触发core dump。于是可以不断地修改代码,不断地GDB调试,不断地增加日志,一步步地追踪根源,一步步地接近真相。
最终通过不断地重复上述步骤找到了core dump的根本原因。其实在写总结文档的时候,core dump的根本原因是什么已经不太重要,最重要的还是解决问题的思路和过程,这才是值得分享和总结的。很多情况下,千辛万苦排查出来的,其实是一个非常明显甚至愚蠢的错误。
比如这次core dump的主要原因是:
由于没有正确地设置non-reusable,并发量太大时,用于异步代理计算的connection结构体被nginx回收并进行了初始化,从而导致不同的事件中出现NULL指针并出CORE。

内存泄漏

虽然解决了core dump,但是另外一个问题又浮出了水面,就是**高并发测试时,会出现内存泄漏,大概一个小时500M的样子**。

valgrind的缺点

出现内存泄漏或者内存问题,大家第一时间都会想到valgrind
valgrind是一款非常优秀的软件,不需要重新编译程序就能够直接测试。功能也非常强大,能够检测常见的内存错误包括内存初始化、越界访问、内存溢出、free错误等都能够检测出来。推荐大家使用。
valgrind 运行的基本原理是:
待测程序运行在valgrind提供的模拟CPU上,valgrind会纪录内存访问及计算值,最后进行比较和错误输出
我通过valgrind测试nginx也发现了一些内存方面的错误,简单分享下valgrind测试nginx的经验:

  1. nginx通常都是使用master fork子进程的方式运行,使用–trace-children=yes来追踪子进程的信息
  2. 测试nginx + openssl时,在使用rand函数的地方会提示很多内存错误。比如Conditional jump or move depends on uninitialised value,Uninitialised value was created by a heap allocation等。这是由于rand数据需要一些熵,未初始化是正常的。如果需要去掉valgrind提示错误,编译时需要加一个选项:-DPURIFY
  3. 如果nginx进程较多,比如超过4个时,会导致valgrind的错误日志打印混乱,尽量减小nginx工作进程,保持为1个。因为一般的内存错误其实和进程数目都是没有关系的。

上面说了valgrind的功能和使用经验,但是valgrind也有一个非常大的缺点,就是它会显著降低程序的性能,官方文档说使用memcheck工具时,降低10-50倍
也就是说,如果nginx完全握手性能是20000 qps,那么使用valgrind测试,性能就只有400 qps左右。对于一般的内存问题,降低性能没啥影响,但是我这次的内存泄漏是在大压力测试时才可能遇到的,如果性能降低这么明显,内存泄漏的错误根本检测不出来。
只能再考虑其他办法了。

AddressSanitizer的优点

address sanitizer(简称asan)是一个用来检测c/c++程序的快速内存检测工具。相比valgrind的优点就是速度快,官方文档介绍对程序性能的降低只有2倍。
对Asan原理有兴趣的同学可以参考asan的算法这篇文章,它的实现原理就是在程序代码中插入一些自定义代码,如下:

和valgrind明显不同的是,asan需要添加编译开关重新编译程序,好在不需要自己修改代码。而valgrind不需要编程程序就能直接运行。
address sanitizer集成在了clang编译器中,GCC 4.8版本以上才支持。我们线上程序默认都是使用gcc4.3编译,于是我测试时直接使用clang重新编译nginx:

由于AddressSanitizer对nginx的影响较小,所以大压力测试时也能达到上万的并发,内存泄漏的问题很容易就定位了。
这里就不详细介绍内存泄漏的原因了,因为跟openssl的错误处理逻辑有关,是我自己实现的,没有普遍的参考意义。
最重要的是,知道valgrind和asan的使用场景和方法,遇到内存方面的问题能够快速修复。

性能热点分析

到此,经过改造的nginx程序没有core dump和内存泄漏方面的风险了。但这显然不是我们最关心的结果(因为代码本该如此),我们最关心的问题是:
1. 代码优化前,程序的瓶颈在哪里?能够优化到什么程度?
2. 代码优化后,优化是否彻底?会出现哪些新的性能热点和瓶颈?
这个时候我们就需要一些工具来检测程序的性能热点。

perf,oprofile,gprof,systemtap

linux世界有许多非常好用的性能分析工具,我挑选几款最常用的简单介绍下:
1. [perf](Perf Wiki)应该是最全面最方便的一个性能检测工具。由linux内核携带并且同步更新,基本能满足日常使用。**推荐大家使用**。
2. oprofile,我觉得是一个较过时的性能检测工具了,基本被perf取代,命令使用起来也不太方便。比如opcontrol –no-vmlinux , opcontrol –init等命令启动,然后是opcontrol –start, opcontrol –dump, opcontrol -h停止,opreport查看结果等,一大串命令和参数。有时候使用还容易忘记初始化,数据就是空的。
3. gprof主要是针对应用层程序的性能分析工具,缺点是需要重新编译程序,而且对程序性能有一些影响。不支持内核层面的一些统计,优点就是应用层的函数性能统计比较精细,接近我们对日常性能的理解,比如各个函数时间的运行时间,,函数的调用次数等,很人性易读。
4. systemtap 其实是一个运行时程序或者系统信息采集框架,主要用于动态追踪,当然也能用做性能分析,功能最强大,同时使用也相对复杂。不是一个简单的工具,可以说是一门动态追踪语言。如果程序出现非常麻烦的性能问题时,推荐使用 systemtap。

这里再多介绍一下perf命令,tlinux系统上默认都有安装,比如通过perf top就能列举出当前系统或者进程的热点事件,函数的排序。
perf record能够纪录和保存系统或者进程的性能事件,用于后面的分析,比如接下去要介绍的火焰图。

火焰图 flame graph

perf有一个缺点就是不直观。火焰图就是为了解决这个问题。它能够以矢量图形化的方式显示事件热点及函数调用关系。
比如我通过如下几条命令就能绘制出原生nginx在ecdhe_rsa cipher suite下的性能热点:

  1. perf record -F 99 -p PID -g — sleep 10
  2. perf script | ./stackcollapse-perf.pl > out.perf-folded
  3. ./flamegraph.pl out.perf-folded>ou.svg

直接通过火焰图就能看到各个函数占用的百分比,比如上图就能清楚地知道rsaz_1024_mul_avx2和rsaz_1024_sqr_avx2函数占用了75%的采样比例。那我们要优化的对象也就非常清楚了,能不能避免这两个函数的计算?或者使用非本地CPU方案实现它们的计算?
当然是可以的,我们的异步代理计算方案正是为了解决这个问题, 从上图可以看出,热点事件里已经没有RSA相关的计算了。至于是如何做到的,后面有时间再写专门的文章来分享。

心态

为了解决上面提到的core dump和内存泄漏问题,花了大概三周左右时间。压力很大,精神高度紧张, 说实话有些狼狈,看似几个很简单的问题,搞了这么长时间。心里当然不是很爽,会有些着急,特别是项目的关键上线期。但即使这样,整个过程我还是非常自信并且斗志昂扬。我一直在告诉自己:

  1. 调试BUG是一次非常难得的学习机会,不要把它看成是负担。不管是线上还是线下,能够主动地,高效地追查BUG特别是有难度的BUG,对自己来说一次非常宝贵的学习机会。面对这么好的学习机会,自然要充满热情,要如饥似渴,回首一看,如果不是因为这个BUG,我也不会对一些工具有更深入地了解和使用,也就不会有这篇文档的产生。
  2. 不管什么样的BUG,随着时间的推移,肯定是能够解决的。这样想想,其实会轻松很多,特别是接手新项目,改造复杂工程时,由于对代码,对业务一开始并不是很熟悉,需要一个过渡期。但关键是,你要把这些问题放在心上。白天上班有很多事情干扰,上下班路上,晚上睡觉前,大脑反而会更加清醒,思路也会更加清晰。特别是白天上班时容易思维定势,陷入一个长时间的误区,在那里调试了半天,结果大脑一片混沌。睡觉前或者上下班路上一个人时,反而能想出一些新的思路和办法。
  3. 开放地讨论。遇到问题不要不好意思,不管多简单,多低级,只要这个问题不是你google一下就能得到的结论,大胆地,认真地和组内同事讨论。这次BUG调试,有几次关键的讨论给了我很大的启发,特别是最后reusable的问题,也是组内同事的讨论才激发了我的灵感。谢谢大家的帮助。

作者介绍  罗成

  • 高级研发工程师,现任职于腾讯TEG基础架构部,对HTTPS、SPDY、HTTP2等应用层协议、高性能服务器技术、用户访问速度及运维技术有较深理解。
  • 曾供职于百度,主导百度安全搜索全站HTTPS的性能优化,作为核心成员实现了百度网盟广告配置文件传输系统及百度早期的持续部署系统。

文章转载自:https://zhuanlan.zhihu.com/p/21348220

A simple Spark test project

NickYang阅读(1221)评论(0)

I start to learn Spark to process some log files, here is a simple example.

How to build Spark, please see http://spark.apache.org/docs/latest/building-spark.html

Scala file

sbt file(use sbt to build this example)

The result is  in result directory, two files, one is _SUCCESS that tells us the right result, the other one is “part-00000”, contains words and words’ count in this text file.

(package,1)
(For,2)
(Programs,1)
(processing.,1)
(Because, 1)
(The,1)
(cluster.,1)
(its,1)
([run,1)
(APIs,1)
(have,1)
(Try,1)

 

BTW. this article is written in Ubuntu, haven’t Chinese input method(English version).

[转]你闺女也能看懂的插画版Kubernetes指南

NickYang阅读(1321)评论(1)

编者按:Matt Butcher是Deis的平台架构师,热爱哲学,咖啡和精雕细琢的代码。有一天女儿走进书房问他什么是Kubernetes,于是就有了这本插画版的Kubernetes指南,讲述了勇敢的Phippy(一个PHP应用),在Kubernetes的冒险故事,满满的父爱有木有!

(视频版建议在wifi环境下打开,土豪请随意)

https://v.qq.com/iframe/preview.html?vid=b0310drhj31&width=500&height=375&auto=0

Hope You Enjoy The Story~

Kubernetes

有一天,女儿走进书房问我:『亲爱的爸爸,什么是Kubernetes呢?』

Kubernetes

我回答她:『Kubernetes是一个开源的Docker容器编排系统,它可以调度计算集群的节点,动态管理上面的作业,保证它们按用户期望的状态运行。通过使用「labels」和「pods」的概念,Kubernetes将应用按逻辑单元进行分组,方便管理和服务发现。』

女儿更疑惑了……于是就有了这个故事

PHP

PHP

很久很久以前,有一个叫Phippy的PHP应用,她很单纯,只有一个页面。她住在一个托管服务里,周围还有很多可怕的应用,她都不认识,也不想去认识,但是他们却要共享这里的环境。所以,她一直都希能有一个属于自己的环境:一个可以称作home的webserver。

PHP

每个应用的运行都要依赖一个环境,对于一个PHP应用来说,这个环境包括了一个webserver,一个可读的文件系统和PHP的engine。

6

有一天,一只可爱的鲸鱼拜访了Phippy,他建议Phippy住在容器里。Phippy听从了鲸鱼的建议搬家了,虽然这个容器看起来很好,但是……怎么说呢,就像是漂浮在海上的一个小房间一样,还是没有家的感觉。

7

不过容器倒是为应用提供了隔离的环境,在这个环境里应用就能运行起来。但是这些相互隔离的容器需要管理,也需要跟外面的世界沟通。共享的文件系统,网络,调度,负载均衡和资源分配都是挑战。

运维

『抱歉……孩子……』鲸鱼耸耸肩,一摇尾消失在了海平面下……Phippy还没有来得及失望,就看到远方驶来一艘巨轮,掌舵的老船长非常威风。这艘船乍一看就是大了点,等到船走近了,Phippy才发现船体两边挂满了皮筏。

老船长用充满智慧的语气对Phippy说:『你好,我是Kube船长』。

9

『Kubernetes』是希腊语中的船长,后来的『Cybernetic』和『Gubernatorial』这两个词就是从Kubernetes衍生来的。Kubernetes项目由Google发起,旨在为生产环境中成千上万的容器,构建一个健壮的平台。

Kubernetes

『您好,我是Phippy。』

『很高兴认识你。』船长边说,边在Phippy身上放了一个name tag。

11

Kubernetes使用label作为『nametag』来区分事物,还可以根据label来查询。label是开放式的:可以根据角色,稳定性或其它重要的特性来指定。

12

Kube船长建议Phippy可以把她的容器搬到船上的pod里,Phippy很高兴地接受了这个提议,把容器搬到了Kube的大船上。Phippy感觉自己终于有家了。

13

在Kubernetes中,pod代表着一个运行着的工作单元。通常,每个pod中只有一个容器,但有些情况下,如果几个容器是紧耦合的,这几个容器就会运行在同一个pod中。Kubernetes承担了pod与外界环境通信的工作。

Kubernetes

Phippy对这一切都感到很新奇,同时她也有很多与众不同的关注点:『如果我想要复制自己该怎么做呢?按需的……任意次数的可以吗?』

『很简单。』船长说道,接着就给Phippy介绍起了replication controller。

15

Replication controller提供了一种管理任意数量pod的方式。一个replication controller包含了一个pod模板,这个模板可以被不限次数地复制。通过replication controller,Kubernetes可以管理pod的生命周期,包括扩/缩容,滚动部署和监控等功能。

Kubernetes

Phippy就这样在船上和自己的副本愉快地生活了好多天。但是每天只能面对自己的副本,这样的生活也太孤单了。

Kube船长慷慨地笑道:『我有好东西给你。』

说着,Kube船长就在Phippy的replication controller和船上其它地方之间建了一个隧道:『就算你们四处移动,这个隧道也会一直待在这里,它可以帮你找到其它pod,其它pod也可以找到你。』

Kubernetes

service可以和Kubernetes环境中其它部分(包括其它pod和replication controller)进行通信,告诉它们你的应用提供什么服务。Pod可以四处移动,但是service的IP地址和端口号是不便、变的。而且其它应用可以通过Kubernetes的服务发现找到你的service。

Kubernetes

有了service,Phippy终于敢去船上其它地方去玩了,她很快就有了新朋友Goldie。有一天,Goldie送了Phippy一件礼物,没想到Phippy只看了一眼就哭了。

『你怎么哭了?』Goldie问道。

『我太喜欢这个礼物了,可惜没地儿放……』Phippy都开始抽泣了。Goldie一听原来是这么回事,马上就告诉Phippy:『为什么不放在一个volume里呢?』

19

Volume代表了一块容器可以访问和存储信息的空间,对于应用来说,volume是一个本地的文件系统。实际上,除了本地存储,Ceph、Gluster、Elastic Block Storage和很多其它后端存储都可以作为volume。

Kubernetes

Phippy渐渐地爱上了船上的生活,她很享受和新朋友的相处(Goldie的每个pod副本也都很nice)。但是回想起以前的生活,她又在想是不是可以有一点点私人空间呢?

Kube船长很理解:『看起来你需要namespace。』

21

Namespace是Kubernetes内的分组机制。Service,pod,replication controller和volume可以很容易地和namespace配合工作,但是namespace为集群中的组件间提供了一定程度的隔离。

22

于是,在Kube船长的船上,Phippy和她的朋友们开始了海上的历险,最重要的是,Phippy找到了自己的家。

从此,Phippy过上了幸福的生活。

原文链接:https://deis.com/blog/2016/kubernetes-illustrated-guide/

周小璐译

原文出处:灵雀云

[转]理解Python装饰器

NickYang阅读(905)评论(0)

作者:xlzd
链接:http://www.zhihu.com/question/26930016/answer/81263287
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。简单来讲,可以不严谨地把Python的装饰器看做一个包装函数的函数。

比如,有一个函数:

运行后将输出:

现在需要在函数运行前后打印一条日志, 但是又不希望或者没有权限修改函数内部的结构, 就可以用到装饰器(decorator):

对于原来的函数”func()”并没有做修改,而是给其使用了装饰器log,运行后的输出为:

把”@log”放到func()函数定义的地方,相当于执行了如下语句:

因为log()返回了一个函数, 所以原本的func指向了log()返回的函数wrapper。wrapper的参数列表为(*args, **kwargs), 所以其可以接受所有的参数调用, 在wrapper中,先打印了一行

‘before function [%s()] run.’ % function.__name__

(在Python中函数也是对象,函数的__name__是它的名字),然后执行了原来的函数并记录了返回值,在输出

‘after function [%s()] run.’ % function.__name__

后返回了函数的执行结果。

如果decorator本身需要传入参数,那就需要编写一个返回decorator的decorator。比如在Flask中:

实现如下:

输出如下:

最后脑洞小开一下, 有没有办法实现既支持不带参数(如log), 又支持带参数(如log(‘text’))的decorator吗?

如上~~~

[转]我在系统设计上犯过的14个错

NickYang阅读(1499)评论(2)

转自:http://hellojava.info/?p=458

在上篇《架构师画像》的文章中提到了自己在系统设计上犯过的一些错,觉得还挺有意义的,这篇文章就来回顾下自己近八年来所做的一些系统设计,看看犯的一些比较大的血淋淋的错误(很多都是推倒重来),这八年来主要做了三个基础技术产品,三个横跨三年的大的技术项目(其中有两个还在进行中),发现大的错误基本集中在前面几年,从这个点看起来能比较自豪的说在最近的几年在系统设计的掌控上确实比以前成熟了很多。

第1个错
在设计服务框架时,我期望服务框架对使用者完全不侵入,于是做了一个在外部放一个.xml文件来描述spring里的哪些bean发布为服务的设计,这个版本发布后,第一个小白鼠的用户勉强在用,但觉得用的很别扭,不过还是忍着用下去了,到了发布的时候,发现出现了两个问题,一是这个xml文件研发也不知道放哪好,所以到了发布的时候都不知道去哪拿这个xml文件。
这个设计的关键错误就在于在设计时没考虑过这个设计方式对研发阶段、运维阶段的影响,后来纠正这个错误的方法是去掉了这个xml文件,改为写了一个Spring FactoryBean,用户在spring的bean配置文件中配置下就可以。
因此对于一个架构师来说,设计时在全面性上要充分考虑。

第2个错
服务框架在核心应用上线时,出现了前端web应用负载高,处理线程数不够用的现象,当时处理这个故障的方式是回滚了服务框架的上线,这个故障排查了比较长的时间后,查到的原因是服务框架用的JBoss Remoting在通信时默认时间是60s,导致一些处理速度慢的请求占据了前端web应用的处理线程池。
上面这里故障的原因简单来说是分布式调用中超时时间太长的问题,但更深层次来思考,问题是犯在了设计服务框架时的技术选型,在选择JBoss-Remoting时没有充分的掌握它的运行细节,这个设计的错误导致的是后来决定放弃JBoss-Remoting,改为基于Mina重写了服务框架的通信部分,这里造成了服务框架的可用版本发布推迟了两个多月。
因此对于一个架构师来说,在技术选型上对技术细节是要有很强的掌控力的。

第3个错
在服务框架大概演进到第4个版本时,通信协议上需要做一些改造,突然发现一个问题是以前的通信协议上是没有版本号的,于是悲催的只能在代码上做一个很龌蹉的处理来判断是新版本还是老版本。
这个设计的错误非常明显,这个其实只要在最早设计通信协议时参考下现有的很多的通信协议就可以避免了,因此这个错误纠正也非常简单,就是参考一些经典的协议重新设计了下。
因此对于一个架构师来说,知识面的广是非常重要的,或者是在设计时对未来有一定的考虑也是非常重要的。

说到协议,就顺带说下,当时在设计通信协议和选择序列化/反序列化上没充分考虑到将来多语言的问题,导致了后来在多语言场景非常的被动,这也是由于设计时前瞻性的缺失,所谓的前瞻性不是说一定要一开始就把未来可能会出现的问题就解掉,而是应该留下不需要整个改造就可以解掉的方法,这点对于架构师来说也是非常重要的。

第4个错
在服务框架切换为Mina的版本上线后,发布服务的应用重启时出现一个问题,就是发现重启后集群中的机器负载严重不均,排查发现是由于这个版本采用是服务的调用方会通过硬件负载均衡去建立到服务发布方的连接,而且是单个的长连接,由于是通过硬件负载均衡建连,意味着服务调用方其实看到的都是同一个地址,这也就导致了当服务发布方重启时,服务调用方重连就会集中的连到存活的机器上,连接还是长连,因此就导致了负载的不均衡现象。
这个设计的错误主要在于没有考虑生产环境中走硬件负载均衡后,这种单个长连接方式带来的问题,这个错误呢还真不太好纠正,当时临时用的一个方法是服务调用方的连接每发送了1w个请求后,就把连接自动断开重建,最终的解决方法是去掉了负载均衡设备这个中间点。
因此对于一个架构师来说,设计时的全面性要非常的好,我现在一般更多采用的方式是推演上线后的状况,一般来说在脑海里过一遍会比较容易考虑到这些问题。

第5个错
服务框架在做了一年多以后,某个版本中出现了一个严重bug,然后我们就希望能通知到用了这个版本的应用紧急升级,在这个时候悲催的发现一个问题是我们压根就不知道生产环境中哪些应用和机器部署了这个版本,当时只好用一个临时的扫全网机器的方法来解决。
这个问题后来纠正的方法是在服务发布和调用者在连接我们的一个点时,顺带把用的服务框架的版本号带上,于是就可以很简单的知道全网的服务框架目前在运行的版本号了。
因此对于一个架构师来说,设计时的全面性是非常重要的,推演能起到很大的帮助作用。

第6个错
服务框架这种基础类型的产品,在发布时会碰到个很大的问题,就是需要通知到使用者去发布,导致了整个发布周期会相当的长,当时做了一个决定,投入资源去实现完全动态化的发布,就是不需要重启,等到做的时候才发现这完全就是个超级大坑,最终这件事在投入两个人做了接近半年后,才终于决定放弃,而且最终来看其实升级的问题也没那么大。
这个问题最大的错误在于对细节把握不力,而且决策太慢。
因此对于一个架构师来说,技术细节的掌控非常重要,同时决策力也是非常重要的。

第7个错
服务发布方经常会碰到一个问题,就是一个服务里的某些方法是比较耗资源的,另外的一些可能是不太耗资源,但对业务非常重要的方法,有些场景下会出现由于耗资源的方法被请求的多了些导致不太耗资源的方法受影响,这种场景下如果要去拆成多个服务,会导致开发阶段还是挺痛苦的,因此服务框架这边决定提供一个按方法做七层路由的功能,服务的发布方可以在一个地方编写一个规则文件,这个规则文件允许按照方法将生产环境的机器划分为不同组,这样当服务调用方调用时就可以做到不同方法调用到不同的机器。
这个功能对有些场景来说用的很爽,但随着时间的演进和人员的更换,能维护那个文件的人越来越少了,也成为了问题。
这个功能到现在为止我自己其实觉得也是一直处于争议中,我也不知道到底是好还是不好…
因此对于一个架构师来说,设计时的全面性是非常重要的。

第8个错
服务框架在用的越来越广后,碰到了一个比较突出的问题,服务框架依赖的jar版本和应用依赖的jar版本冲突,服务框架作为一个通用技术产品,基本上没办法为了一个应用改变服务框架自己依赖的jar版本,这个问题到底怎么去解,当时思考了比较久。
可能是由于我以前OSGi这块背景的原因,在设计上我做了一个决定,引入OSGi,将服务框架的一堆jar处于一个独立的classloader,和应用本身的分开,这样就可以避免掉jar冲突的问题,在我做了引入OSGi这个决定后,团队的1个资深的同学就去做了,结果是折腾了近两个月整个匹配OSGi的maven开发环境都没完全搭好,后来我自己决定进去搞这件事,即使是我对OSGi比较熟,也折腾了差不多1个多月才把整个开发的环境,工程的结构,以及之前的代码基本迁移为OSGi结构,这件事当时折腾好上线后,效果看起来是不错的,达到了预期。
但这件事后来随着加入服务框架的新的研发人员越来越多,发现多数的新人都在学习OSGi模式的开发这件事上投入了不少的时间,就是比较难适应,所以后来有其他业务问是不是要引入OSGi的时候,我基本都会建议不要引入,主要的原因是OSGi模式对大家熟悉的开发模式、排查问题的冲击,除非是明确需要classloader隔离、动态化这两个点。
让我重新做一个决策的话,我会去掉对OSGi的引入,自己做一个简单的classloader隔离策略来解决jar版本冲突的问题,保持大家都很熟悉的开发模式。
因此对于一个架构师来说,设计时的全面性是非常重要的。

第9个错
服务框架在用的非常广了后,团队经常会被一个问题困扰和折腾,就是业务经常会碰到调用服务出错或超时的现象,这种情况通常会让服务框架这边的研发来帮助排查,这个现象之所以查起来会比较复杂,是因为服务调用通常是多层的关系,并不是简单的A–>B的问题,很多时候都会出现A–>B–>C–>D或者更多层的调用,超时或者出错都有可能是在其中某个环节,因此排查起来非常麻烦。
在这个问题越来越麻烦后,这个时候才想起在09年左右团队里有同学看过G家的一篇叫dapper的论文,并且做了一个类似的东西,只是当时上线后我们一直想不明白这东西拿来做什么,到了排查问题这个暴露的越来越严重后,终于逐渐想起这东西貌似可以对排查问题会产生很大的帮助。
到了这个阶段才开始做这件事后,碰到的主要不是技术问题,而是怎么把新版本升级上去的问题,这个折腾了挺长时间,然后上线后又发现了一个新的问题是,即使服务框架具备了Trace能力,但服务里又会调外部的例如数据库、缓存等,那些地方如果有问题也会看不到,排查起来还是麻烦,于是这件事要真正展现效果就必须让Trace完全贯穿所有系统,为了做成这件事,N个团队付出了好几年的代价。
因此对于一个架构师来说,设计时的全面性、前瞻性非常重要,例如Trace这个的重要性,如果在最初就考虑到,那么在一开始就可以留好口子埋好伏笔,后面再要做完整就不会太复杂。

第10个错
服务的发布方有些时候会碰到一个现象是,服务还没完全ready,就被调用了;还有第二个现象是服务发布方出现问题时,要保留现场排查问题,但服务又一直在被调用,这种情况下就没有办法很好的完全保留现场来慢慢排查问题了。
这两个现象会出现的原因是服务框架的设计是通过启动后和某个中心建立连接,心跳成功后其他调用方就可以调用到,心跳失败后就不会被调到,这样看起来很自动化,但事实上会导致的另外一个问题是外部控制上下线这件事的能力就很弱。
这个设计的错误主要还是在设计时考虑的不够全面。
因此对于一个架构师来说,设计时的全面性非常重要。

第11个错
在某年我和几个小伙伴决定改变当时用xen的模式,换成用一种轻量级的“虚拟机”方式来做,从而提升单机跑的应用数量的密度,在做这件事时,我们决定自己做一个轻量级的类虚拟机的方案,当时决定的做法是在一个机器上直接跑进程,然后碰到一堆的问题,例如从运维体系上来讲,希望ssh到“机器”、独立的ip、看到自己的系统指标等等,为了解决这些问题,用了N多的黑科技,搞得很悲催,更悲催的是当时觉得这个问题不多,于是用一些机器跑了这个模式,结果最后发现这里面要黑科技解决的问题实在太多了,后来突然有个小伙伴提出我们试用lxc吧,才发现我们之前用黑科技解的很多问题都没了,哎,然后就是决定切换到这个模式,结果就是线上的那堆机器重来。
这个设计的主要错误在于知识面不够广,导致做了个不正确的决定,而且推倒重来。
因此对于一个架构师来说,知识面的广非常重要,在技术选型这点上非常明显。

第12个错
还是上面这个技术产品,这个东西有一个需求是磁盘空间的限额,并且要支持磁盘空间一定程度的超卖,当时的做法是用image的方式来占磁盘空间限额,这个方式跑了一段时间觉得没什么问题,于是就更大程度的铺开了,但铺开跑了一段时间后,出现了一个问题,就是经常出现物理机磁盘空间不足的报警,而且删掉了lxc容器里的文件也还是不行,因为image方式只要占用了就会一直占着这个大小,只会扩大不会缩小。
当时对这个问题极度的头疼,只能是删掉文件后,重建image,但这个会有个要求是物理机上有足够的空间,即使有足够的空间,这个操作也是很折腾人的,因为得先停掉容器,cp文件到新创建的容器,这个如果东西多的话,还是要耗掉一定时间的。
后来觉得这个模式实在是没法玩,于是寻找新的解决方法,来满足磁盘空间限额,允许超卖的这两需求,最后我们也是折腾了比较长一段时间后终于找到了更靠谱的解决方案。
这个设计的主要错误还是在选择技术方案时没考虑清楚,对细节掌握不够,考虑的面不够全,导致了后面为了换掉image这个方案,用了极大的代价,我印象中是一堆的人熬了多次通宵来解决。
因此对于一个架构师来说,知识面的广、对技术细节的掌控和设计的全面性都非常重要。

第13个错
仍然是上面的这个技术产品,在运行的过程中,突然碰到了一个虚拟机中线程数创建太多,导致其他的虚拟机也创建不了线程的现象(不是因为物理资源不够的问题),排查发现是由于尽管lxc支持各个容器里跑相同名字的账号,但相同名字的账号的uid是相同的,而max processes是限制在UID上的,所以当一个虚拟机创建的线程数超过时,就同样影响到了其他相同账号的容器。
这个问题我觉得一定程度也可以算是设计问题,设计的时候确实由于对细节掌握的不够,考虑的不全导致忽略了这个点。
因此对于一个架构师来说,对技术细节的掌控和设计的全面性都非常重要。

第14个错
在三年前做一个非常大的项目时,项目即将到上线时间时,突然发现一个问题是,有一个关键的点遗漏掉了,只好赶紧临时讨论方案决定怎么做,这个的改动动作是非常大的,于是项目的上线时间只能推迟,我记得那个时候紧急周末加班等搞这件事,最后带着比较高的风险上了。
这个问题主要原因是在做整体设计时遗漏掉了这个关键点的考虑,当时倒不是完全忽略了这个点,而是在技术细节上判断错误,导致以为不太要做改动。
因此对于一个架构师来说,对技术细节的掌控是非常重要的,这里要注意的是,其实不代表架构师自己要完全什么都很懂,但架构师应该清楚在某个点上靠谱的人是谁。

[转]为什么我们抛弃ECS而选择了Kubernetes

NickYang阅读(2327)评论(2)

转载自:http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=401368207&idx=1&sn=6bb2b3fe6ece8f41e7f2e2a54f52e46c&scene=1&srcid=0113d03chnJkdvhm86dmBSyW#rd
2016-01-13 杨润青 译  Docker

在这篇文章中我们将会探讨2个主流的Docker编排框架:AWS的ECS(Elastic Container Service)和Google的Kubernetes。

3个月前,我们在nanit.com希望选择一个合适的Docker编排框架,ECS成为了我们的首选,毕竟,我们对AWS的服务较为熟悉,并且我们的基础设施都是建立在AWS的。经过一段时间的测试,我们发现ECS并不成熟,缺少一些我们需要的关键功能,因此我们开始尝试其他的框架:Kubernetes。令人意外的是,Kubernetes非常成熟,几乎支持我们需要的所有功能。对于我们来说,Kubernetes在ECS的主场完胜了ECS。接下来,就让我们一起来看看Kubernetes赢在哪些方面。

注意:ECS一直在更新,我们会尽可能的跟进这些内容,但部分内容可能被忽略了,希望读者不要介意。

构建集群(Cluster Setup)

ECS:为了启动一个ECS集群,用户需要设置一个Auto Scaling Group。用户可以编辑user-data来将EC2实例添加到指定的ECS集群上。当ASG被设置,实例启动之后,用户可以在ECS控制台看到这部分内容。现在,用户可以开始进行task-definition,方式类似于Docker-compose。

Kubernetes:想要在AWS上启动一个Kubernetes,用户需要先启动一个具有一定权限的EC2实例(通过IAM)。这将会创建多个AWS constructs来支持你的集群:VPC、ASG、一些安全组(Security Groups)和一个Kubernetes主实例。集群需要几分钟来启动,之后用户就能够在上面运行自己的容器。

比较结果:使用这两种框架来启动一个集群都非常的简单和友好。

启动基础服务(Basic Service Setup)

我们的任务是启动一个Nginx 镜像,并且让其他人能够访问这个Web服务。

ECS:首先,我们需要创建一个ELB(Elastic Load Balancer),它负责80端口的转发。然后,我们需要创建一个task-definition,它负责在80端口上启动一个Docker镜像。最后,需要创建一个Service,它会显示出有多少实例会同时运行。我们需要将它绑定到我们之前创建的ELB上。

Kubernetes:首先需要创建一个Replication Controller,它会显示出我们希望运行的Docker镜像和有多少镜像会同时运行。之后,我们需要创建一个Service object,这会启动一个ELB并且将ELB的流量转发到对应的容器上。

比较结果:Kubernetes的方式更舒服一些,更简洁。用户并不需要手工启动或者管理ELB。Kubernetes会完全负责管理:当用户创建了一个service,一个ELB会自动创建;当用户删除了一个service,它会自动从AWS上删除。

服务发现(Service Discovery)

当你使用了微服务架构和Docker,一个好的服务发现解决方案是至关重要的。Docker容器总是在不同虚拟机中迁移,用户必须有一个可靠的方法来发现在集群内和集群外的服务。

ECS:ECS并没有提供任何服务发现的解决方案。我能想到的最好方法就是构建一个内部加载平衡器(internal load balancer),并且将每一个service附加到一个平衡器上。平衡器的host name不会被改变,然后你就能够利用这个host name来作为服务的端点。其他的方法还有集成一个外部的程序,比如Consul。

Kubernetes:我认为这是Kubernetes的亮点之一。Kubernetes内置了一个完全的解决方案。它是一个插件,因此用户可以选择是否使用,但我强烈建议使用。它能够和namespace一起很好的工作。简单来说,当你创建了一个Kubernetes服务,比如说叫做redis,你就能够在集群的任何地方引用redis这个名字,即便是跨虚拟机。这就像是让docker网络跨越了特定的虚拟机,连通了整个集群。Namespaces允许你将多个服务归纳到一个具有逻辑的组中。现在假设我们有两个命名空间,分别是production和staging,他们都包含有一个redis的服务。一个在production命名空间下的容器可以通过redis来引用在production命名空间下的redis服务,同样的,在stagin命名空间下的容器也能通过redis来引用到位于stagine命名空间下的redis服务。这种自动化识别使得用户不需要花费时间去配置信息就能够构建一个隔离的环境,并且你可以随意在所有的命名空间中使用redis来引用对应的服务,接下来kunernetes会为你自动解析它们。

比较结果:毫无疑问,Kubernetes小胜一局。使用Kubernetes,用户完全不用关心服务发现的事情,全部交给Kubernetes来做就好了:)

部署(Deployments)

当我们升级一个服务的时候,即便还在部署,我们也想要确保它百分之百能用。我们的测试包括一个简单的NginX服务和一些简单的静态网页。我们启动了一个并发为30个请求的负载测试,并且在负载测试期间,我们会对该服务进行升级。

在部署期间,我们发现ECS丢失了比Kubernetes更多的请求。其中,Kubernetes丢失了0-2个请求,而ECS丢失了9-14个。

比较结果:说实话,我对ECS非常的失望。同样,我也对Kubernetes表示失望,但是它至少比ECS好多了。值得注意的是,Kubernetes 1.1.1版本应该会对轮询升级机制(rollong update mechanism)进行改善,还有一些其他的系统系能提升,这些改进都会使得这些数字变得更好看。

持久卷(Persistent Volumes)

我们经常需要挂载一些持久性的文件系统到一个指定的容器上,MySQL就是一个典型的例子。

ECS:ECS支持Docker原生的解决方案——用户可以启动一个数据容器,然后使用volumes-from命令来挂载它到其他容器上。就拿MySQL来看,你首先需要设置一个mysql-data容器,这个容器仅仅拥有一个数据卷。然后设置另外一个mysql-db容器,这个容器使用volumes-from命令来挂载之前创建的数据卷容器。这个方法看起来不错,但是它是host-sepicific的,这意味着你的mysql-db容器不能够在主机之间移动。你必须指定mysql-db容器在哪一个主机上运行,以此来防止容器被重新分配到其他主机上,最终失去了持久性。

Kubernetes:除了从一个指定的主机上挂载数据卷,Kubernetes还提供了一个选项:挂载一个EBS(Elastic Book Store)数据卷。这意味着一个容器的持久性存储可以在多个不同的虚拟机之间保留。你再也不需要强制你的MySQL容器必须运行在哪一个具体的虚拟机上。

注意:EBS同一时间只能被一个虚拟机挂载,这意味着如果有一个服务,它有两个运行在不同虚拟机的容器,他们将不能够挂载和共享这个EBS。

比较结果:即便Kubernetes的EBS挂载有一定的限制,但它依旧非常的独特和有用。

健康检查(Health-Checks)

确保拥有足够的服务容量是高可用性和冗余性的核心思想。健康检查就是用来确保服务不仅仅是运行的,并且它们还是健康和可操作的。

ECS:ECS使用ELB(Elastic Load Balancer)健康检查,这种方式有三个主要的缺点:

  1. ELB健康检查仅仅限于HTTP/TCP检查
  2. 如果你想要对一个不开放TCP端口的服务进行检查,这是不行的。仅仅是为了能够进行健康检查,你就必须运行一个HTTP/TCP服务器。
  3. 即便你拥有一个支持HTTP/TCP的服务,你还需要创建一个ELB,并将它绑定到这个服务上,这样才能进行健康检查。

Kubernetes:除了基于HTTP/TCP的健康检查,Kubernetes还提供了一种叫做Exec的方式。Exec可以让用户在容器中运行命令。如果命令结束,并且返回0则表示这个服务是健康的,否则这个服务很可能是不健康的,它会被其他的实例所替换。

比较结果:Kubernetes的方式更灵活,更简单配置。用户并不需要去启动一个冗余的HTTP/TCP服务器仅仅为了进行健康检查,并且即便服务没有绑定ELB,你也可以对它们进行健康检查。

端口管理(Port Management)

从我们的上篇文章中可以看出,端口管理在Docker中是比较困难的。我们想通过一个简单的例子来说明Kubernetes如何比ECS更优雅的解决了这个问题。我们拥有一台虚拟机和两个监听80端口的网站。我们不能够在同一个虚拟机上开2个80端口,因此我们需要寻找一个方法来解决这个问题。

ECS:用户必须手工确定两个服务没有使用同一个端口。我们只有一台虚拟机,因此只能运行一个开放80端口的容器。当我们想要开启第二个开放80端口的容器时,这是不行的,因为我们没有多余的虚拟机了。也就是说,能够开放多少个x端口的服务取决于拥有多少个虚拟机。在小型集群中,这是非常容易满足的条件,但是当你的服务数量变得越来越多时,这将成为一个头疼的问题,因为当你想要扩充容器时,你必须确认你还有足够的端口。

Kubernetes:Kubernetes非常优雅的解决了这个问题。它为每一个虚拟机上的容器都分配了一个随机的端口。然后它创建了2个ELB,一个将80端口转发到容器A的随机端口上,另外一个转发到容器B的随机端口上。一个内部的路由机制会负责将数据包转发到对应容器端口。

比较结果:Kubernetes使用虚拟端口的方式代替绑定原始端口的方法,很好的解决了这个头疼的问题。

记录(Logging)

没有什么系统不需要记录功能。

我从没有想过记录会成为一个大问题,但能够为你解决问题令我非常的高兴,即便这个问题非常简单。我们之前提到Kubernetes提供了一个服务发现的扩展功能,在这里,我想说的是记录的扩展功能。它含有两个不同的记录和度量收集(metric collection)的机制。第一种是著名的ELK方法,ELK会收集容器的所有记录,并且能够让用户通过Kibana接口来查询和可视化这些记录。第二种是InfluxDB,它使用Grafana作为可视化工具来查询系统信息,如CPU和内存使用情况。

比较结果:Kubernetes的扩展功能更胜一筹。当然,你会说我并不需要这些扩展,系统也能很好工作,但是,它们效果如此之好,并且能适用于99%的用例,为什么不使用呢?ECS并没有提供内置的记录功能,用户想要集成一个进去并不是很困难,但是这些并不能和Kubernetes提供的功能相提并论。

未知的云平台(Cloud Agnostic)

其实,Kubernetes和ECS之间并不存在竞争:)

ECS会专注于AWS平台,如果你已经在ECS上构建了你的基础架构,当你想要转移到其他云平台时,你将会遇到很多困难。

Kubernetes适用于多个云平台。你可以在AWS,Google Cloud,微软的ZURE,Rackspace等等上运行你的集群,并且运行效果或多或少都是相同的。在这里,或多或少指的是有一些功能只有部分云供应商提供。你必须确认你选择的新供应商能够支持Kubernetes中使用的功能,至少确保迁移是可能的。

开源软件(OSS)

Kubernetes是开源的项目,而ECS不是。这意味着,所有的一切,从源代码到未来的发展路线都是对你开放的。发现了漏洞?你可以创建一个issue或者直接提交一个pull 请求来修复它。新的功能会被添加到每一个新版本,其中的贡献人数和pull请求是惊人的。

ECS有着不同的性质,我不能够在网上找到关于它未来发展路线的规划。你不能够获得一个漏洞和issue的列表,你必须深入到论坛上去寻找想要的答案。并且你寻找的答案往往都是缺乏实际的,并不能够提供任何帮助(https://forums.aws.amazon.com/message.jspa?messageID=664865#664865)。也许这仅仅是因为我个人的糟糕经历,但是不管怎么说,这都是令人烦躁和失望的。

比较结果:就我个人而言,我更喜欢开源软件。我喜欢Kubernetes的开放性,每个人都能够参与讨论和贡献代码。我相信社区的力量会给我们带来一个更好的产品。

多可用区域(Multi-AZ)

当谈论到Kubernetes时,有一件事情困扰着我:它不支持AWS上的多可用区域集群(multiple availability-zones cluters)。这意味着所有EC2实例都集中在一个AZ上,这使得你的集群很可能会遭受到中断问题。

ECS有对Multi-AZ有很好的支持。

比较结果:在Kubernetes的issue上,已经有一些工作正在进行。我十分确定下个版本会很好的得到改善。因此ECS在这一点上的胜利并不会长久。

总结

很多公司都开始使用Doker作为他们的主要基础设置,传递机制(delivery mechanism)和编排框架(orchestration frameworks)成为了系统的核心,并且影响着我们开发,迁移,运行,升级的方式。当我想要比较ECS和Kubernetes时,我找不到类似的文章。所以我认为把我们的经验公布出来非常的重要,这样其他人能够站在我们的肩膀上看的更远。

对于nanit.com来说,Kubernetes毫无疑问获得了胜利。如果你有任何的异议,请告诉我理由,我非常想要知道这些内容:)

什么时候需要学一门新的编程语言?

NickYang阅读(2416)评论(3)

声明:本文没有任何褒贬或者对比各种编程语言的意思,请不要做无谓的语言之争。

我们这些80后程序员大部分人都是从delphi,C,C++开始接触编程的,然后等到了大学或者工作,因为生计或者其他种种原因,大家从事的行业开始有了变化,从而导致开发语言也有了一些变化,一些做后端的,开始使用Java,C++等等,一些做前端的开始用php,js等等。

然而,当我们用一门语言很久之后,就会对这门语言有了更多更深刻的了解,优点缺点、解决方案等等,而且大部分人会有一中喜新厌旧的心里,再加上市面上的新语言、新特性层出不绝,特别是看到那些你曾经花了很大精力想了各种奇淫技巧解决了一个问题,而在某些新语言中这只是一个普通特性,所以大家难免会心里痒痒,“我要不要学这个新语言,我要不要在工作环境中使用这个语言?”

这篇文章我就两方面讲下什么时候需要学一门编程语言,一个是学新语言是否真的对你的开发工作有帮助,一个是你的生活工作环境中是否允许你用新的语言。因为我是从事游戏服务器开发,主要语言是C++,而我打算学习C#,以下的内容就用这两门语言做例子。

学新语言是否真的对你的开发工作有帮助?

我们学习任何东西都是建立在有需要的情况下,如果知识不能转化成财富,估计很少有人会去上学。所以学一门新的编程语言是否对我们有帮助是很重要的,不过如果你只是单纯的兴趣,那倒是无所谓。学习新语言的原因基本分为下面几种:

  • 现在的语言太复杂,很多特性非常老,实现功能起来很纠结,需要一门简单实用的新语言快速解决问题,新语言简洁高效,特性强大
  • 现在的语言需要大量的第三方库,而新语言自带平常开发的大部分库
  • 现在的语言开发效率太低,新语言分分钟撸一个功能模块出来

上面的几点,总结起来就是现在的语言用起来很不爽,需要新语言来帮助我提高效率。

简单高效一直是现代编程语言的核心思想,通过C++ 11,14,17标准我们很明显的看出来,C++当初为了兼容C(挖C程序员的墙角),做了很多现在看来很纠结的东西,而新标准就是在改善这块东西。我们团队维护的NFrame C++版本,到了现在又开始用C#语言做一个,核心思想没变,只是单纯的换个语言,现在核心功能已经换完了,只花了两周多的时间,一个库都没依赖,只依赖了.Net Framework,杂七杂八架起来只有10M多,而C++版本库解压后有近1G,从开发和维护成本上来说,都是C#更胜一筹。再加上现在MS本身已经开始支持跨平台了,或者mono,跨平台根本不是问题。

这个例子可以看出,新的语言C#确实提高了我们的开发效率,而C#的Task等等特性和内容,已经将我们再C++上纠结的Actor模式完全替代了,让我们可以安心做功能设计,而不是纠结语言层面的实现问题。

而且新语言一般都是通杀的,web,UI,back-end等,基本都支持,C#,js,Java都是前后端通杀,适合大部分领域和行业。

//TODO

 

生活工作环境中是否允许你用新的语言?

俗话说兴趣是最好的老师,当你对某个事物有了兴趣之后,自然就有学习的动力了。但是我们都不是一个人在战斗,多多少少都会有合作的同事、朋友,小到自己的简单开源项目,大到公司的大项目,所以工作生活中都是多个人在合作,做任何事情都不能一意孤行,自己喜欢某种编程语言就大用特用,毕竟团队整体的效率才是执行力,现在已经不是个人英雄主义的时代了,保持合作交流才能有更大的进步。团队做出来的东西才是外面比较看重的,技术不是决定性因素,而项目产品才是提升自己价值的东西,离开团队这个平台,一身是铁打几根钉子?面面俱到方能做到完美。

 

暂时想到的就是这么多了,大家可以继续补充讨论。

[转]单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构

NickYang阅读(1810)评论(1)

此文是根据杨尚刚在【QCON高可用架构群】中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处。

杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计。前新浪高级数据库工程师,负责新浪微博核心数据库架构改造优化,以及数据库相关的服务器存储选型设计。

前言

MySQL数据库大家应该都很熟悉,而且随着前几年的阿里的去IOE,MySQL逐渐引起更多人的重视。

MySQL历史

  • 1979年,Monty Widenius写了最初的版本,96年发布1.0
  • 1995-2000年,MySQL AB成立,引入BDB
  • 2000年4月,集成MyISAM和replication
  • 2001年,Heikki Tuuri向MySQL建议集成InnoDB
  • 2003发布5.0,提供了视图、存储过程等功能
  • 2008年,MySQL AB被Sun收购,09年推出5.1
  • 2009年4月,Oracle收购Sun,2010年12月推出5.5
  • 2013年2月推出5.6 GA,5.7开发中

MySQL的优点

  • 使用简单
  • 开源免费
  • 扩展性“好”,在一定阶段扩展性好
  • 社区活跃
  • 性能可以满足互联网存储和性能需求,离不开硬件支持

上面这几个因素也是大多数公司选择考虑MySQL的原因。不过MySQL本身存在的问题和限制也很多,有些问题点也经常被其他数据库吐槽或鄙视

MySQL存在的问题

  • 优化器对复杂SQL支持不好
  • 对SQL标准支持不好
  • 大规模集群方案不成熟,主要指中间件
  • ID生成器,全局自增ID
  • 异步逻辑复制,数据安全性问题
  • Online DDL
  • HA方案不完善
  • 备份和恢复方案还是比较复杂,需要依赖外部组件
  • 展现给用户信息过少,排查问题困难
  • 众多分支,让人难以选择

看到了刚才讲的MySQL的优势和劣势,可以看到MySQL面临的问题还是远大于它的优势的,很多问题也是我们实际需要在运维中优化解决的,这也是MySQL DBA的一方面价值所在。并且MySQL的不断发展也离不开社区支持,比如Google最早提交的半同步patch,后来也合并到官方主线。Facebook Twitter等也都开源了内部使用MySQL分支版本,包含了他们内部使用的patch和特性。

数据库开发规范

数据库开发规范定义:开发规范是针对内部开发的一系列建议或规则, 由DBA制定(如果有DBA的话)。

开发规范本身也包含几部分:基本命名和约束规范,字段设计规范,索引规范,使用规范。

规范存在意义

  • 保证线上数据库schema规范
  • 减少出问题概率
  • 方便自动化管理
  • 规范需要长期坚持,对开发和DBA是一个双赢的事情

想想没有开发规范,有的开发写出各种全表扫描的SQL语句或者各种奇葩SQL语句,我们之前就看过开发写的SQL 可以打印出好几页纸。这种造成业务本身不稳定,也会让DBA天天忙于各种救火。

基本命名和约束规范

  • 表字符集选择UTF8 ,如果需要存储emoj表情,需要使用UTF8mb4(MySQL 5.5.3以后支持)
  • 存储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • 单表数据量控制在1亿以下
  • 库名、表名、字段名不使用保留字
  • 库名、表名、字段名、索引名使用小写字母,以下划线分割 ,需要见名知意
  • 库表名不要设计过长,尽可能用最少的字符表达出表的用途

字段规范

  • 所有字段均定义为NOT NULL ,除非你真的想存Null
  • 字段类型在满足需求条件下越小越好,使用UNSIGNED存储非负整数 ,实际使用时候存储负数场景不多
  • 使用TIMESTAMP存储时间
  • 使用varchar存储变长字符串 ,当然要注意varchar(M)里的M指的是字符数不是字节数;使用UNSIGNED INT存储IPv4 地址而不是CHAR(15) ,这种方式只能存储IPv4,存储不了IPv6
  • 使用DECIMAL存储精确浮点数,用float有的时候会有问题
  • 少用blob text

关于为什么定义不使用Null的原因

* 1.浪费存储空间,因为InnoDB需要有额外一个字节存储

* 2.表内默认值Null过多会影响优化器选择执行计划

关于使用datatime和timestamp,现在在5.6.4之后又有了变化,使用二者存储在存储空间上大差距越来越小 ,并且本身datatime存储范围就比timestamp大很多,timestamp只能存储到2038年

索引规范

  • 单个索引字段数不超过5,单表索引数量不超过5,索引设计遵循B+ Tree索引最左前缀匹配原则
  • 选择区分度高的列作为索引
  • 建立的索引能覆盖80%主要的查询,不求全,解决问题的主要矛盾
  • DML和order by和group by字段要建立合适的索引
  • 避免索引的隐式转换
  • 避免冗余索引

关于索引规范,一定要记住索引这个东西是一把双刃剑,在加速读的同时也引入了很多额外的写入和锁,降低写入能力,这也是为什么要控制索引数原因。之前看到过不少人给表里每个字段都建了索引,其实对查询可能起不到什么作用。

冗余索引例子

  • idx_abc(a,b,c)
  • idx_a(a) 冗余
  • idx_ab(a,b) 冗余

隐式转换例子

字段:remark varchar(50) NOT Null

MySQL>SELECT id, gift_code FROM gift WHERE deal_id = 640 AND remark=115127; 1 row in set (0.14 sec)

MySQL>SELECT id, gift_code FROM pool_gift WHEREdeal_id = 640 AND remark=‘115127’; 1 row in set (0.005 sec)

字段定义为varchar,但传入的值是个int,就会导致全表扫描,要求程序端要做好类型检查

SQL类规范

  • 尽量不使用存储过程、触发器、函数等
  • 避免使用大表的JOIN,MySQL优化器对join优化策略过于简单
  • 避免在数据库中进行数学运算和其他大量计算任务
  • SQL合并,主要是指的DML时候多个value合并,减少和数据库交互
  • 合理的分页,尤其大分页
  • UPDATE、DELETE语句不使用LIMIT ,容易造成主从不一致

数据库运维规范

运维规范主要内容

  • SQL审核,DDL审核和操作时间,尤其是OnlineDDL
  • 高危操作检查,Drop前做好数据备份
  • 权限控制和审计
  • 日志分析,主要是指的MySQL慢日志和错误日志
  • 高可用方案
  • 数据备份方案

版本选择

  • MySQL社区版,用户群体最大
  • MySQL企业版,收费
  • Percona Server版,新特性多
  • MariaDB版,国内用户不多

建议选择优先级为:MySQL社区版 > Percona Server > MariaDB > MySQL 企业版

不过现在如果大家使用RDS服务,基本还以社区版为主

Online DDL问题

原生MySQL执行DDL时需要锁表,且锁表期间业务是无法写入数据的,对服务影响很大,MySQL对这方面的支持是比较差的。大表做DDL对DBA来说是很痛苦的,相信很多人经历过。如何做到Online DDL呢,是不是就无解了呢?当然不是!

上面表格里提到的 Facebook OSC和5.6 OSC也是目前两种比较靠谱的方案

MySQL 5.6的OSC方案还是解决不了DDL的时候到从库延时的问题,所以现在建议使用Facebook OSC这种思路更优雅

下图是Facebook OSC的思路

后来Percona公司根据Facebook OSC思路,用perl重写了一版,就是我们现在用得很多的pt-online-schema-change,软件本身非常成熟,支持目前主流版本。

使用pt-online-schema-change的优点有:

  • 1.无阻塞写入
  • 2.完善的条件检测和延时负载策略控制

值得一提的是,腾讯互娱的DBA在内部分支上也实现了Online DDL,之前测试过确实不错,速度快,原理是通过修改InnoDB存储格式来实现。

使用pt-online-schema-change的限制有:

  • 改表时间会比较长(相比直接alter table改表)
  • 修改的表需要有唯一键或主键
  • 在同一端口上的并发修改不能太多

可用性

关于可用性,我们今天分享一种无缝切主库方案,可以用于日常切换,使用思路也比较简单

在正常条件下如何无缝去做主库切换,核心思路是让新主库和从库停在相同位置,主要依赖slave start until 语句,结合双主结构,考虑自增问题。

MySQL集群方案:

  • 集群方案主要是如何组织MySQL实例的方案
  • 主流方案核心依然采用的是MySQL原生的复制方案
  • 原生主从同步肯定存在着性能和安全性问题

MySQL半同步复制:

现在也有一些理论上可用性更高的其它方案

  • Percona XtraDB Cluster(没有足够的把控力度,不建议上)
  • MySQL Cluster(有官方支持,不过实际用的不多)

红框内是目前大家使用比较多的部署结构和方案。当然异常层面的HA也有很多第三方工具支持,比如MHA、MMM等,推荐使用MHA

sharding拆分问题

  • Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
  • sharding是按照一定规则数据重新分布的方式
  • 主要解决单机写入压力过大和容量问题
  • 主要有垂直拆分和水平拆分两种方式
  • 拆分要适度,切勿过度拆分
  • 有中间层控制拆分逻辑最好,否则拆分过细管理成本会很高

曾经管理的单表最大60亿+,单表数据文件大小1TB+,人有时候就要懒一些

上图是水平拆分和垂直拆分的示意图

数据库备份

首先要保证的,最核心的是数据库数据安全性。数据安全都保障不了的情况下谈其他的指标(如性能等),其实意义就不大了。

备份的意义是什么呢?

  • 数据恢复!
  • 数据恢复!
  • 数据恢复!

目前备份方式的几个纬度:

  • 全量备份 VS 增量备份
  • 热备 VS 冷备
  • 物理备份 VS 逻辑备份
  • 延时备份
  • 全量binlog备份

建议方式:

  • 热备+物理备份
  • 核心业务:延时备份+逻辑备份
  • 全量binlog备份

借用一下某大型互联网公司做的备份系统数据:一年7000+次扩容,一年12+次数据恢复,日志量每天3TB,数据总量2PB,每天备份数据量百TB级,全年备份36万次,备份成功了99.9%。

主要做的几点:

  • 备份策略集中式调度管理
  • xtrabackup热备
  • 备份结果统计分析
  • 备份数据一致性校验
  • 采用分布式文件系统存储备份

备份系统采用分布式文件系统原因:

  • 解决存储分配的问题
  • 解决存储NFS备份效率低下问题
  • 存储集中式管理
  • 数据可靠性更好

使用分布式文件系统优化点:

* Pbzip压缩,降低多副本存储带来的存储成本,降低网络带宽消耗

* 元数据节点HA,提高备份集群的可用性

* erasure code方案调研

数据恢复方案

目前的MySQL数据恢复方案主要还是基于备份来恢复,可见备份的重要性。比如我今天下午15点删除了线上一张表,该如何恢复呢?首先确认删除语句,然后用备份扩容实例启动,假设备份时间点是凌晨3点,就还需要把凌晨3点到现在关于这个表的binlog导出来,然后应用到新扩容的实例上,确认好恢复的时间点,然后把删除表的数据导出来应用到线上。

性能优化

复制优化

MySQL复制:

  • 是MySQL应用得最普遍的应用技术,扩展成本低
  • 逻辑复制
  • 单线程问题,从库延时问题
  • 可以做备份或读复制

问题很多,但是能解决基本问题

上图是MySQL复制原理图,红框内就是MySQL一直被人诟病的单线程问题

单线程问题也是MySQL主从延时的一个重要原因,单线程解决方案:

  • 官方5.6+多线程方案
  • Tungsten为代表的第三方并行复制工具
  • sharding

上图是MySQL5.6 目前实现的并行复制原理图,是基于库级别的复制,所以如果你只有一个库,使用这个意义不大

当然MySQL也认识到5.6这种并行的瓶颈所在,所以在5.7引入了另外一种并行复制方式,基于logical timestamp的并行复制,并行复制不再受限于库的个数,效率会大大提升

上图是5.7的logical timestamp的复制原理图

刚才我也提到MySQL原来只支持异步复制,这种数据安全性是非常差的,所以后来引入了半同步复制,从5.5开始支持

上图是原生异步复制和半同步复制的区别。可以看到半同步通过从库返回ACK这种方式确认从库收到数据,数据安全性大大提高

在5.7之后,半同步也可以配置你指定多个从库参与半同步复制,之前版本都是默认一个从库

对于半同步复制效率问题有一个小的优化,就是使用5.6+的mysqlbinlog以daemon方式作为从库,同步效率会好很多

关于更安全的复制,MySQL 5.7也是有方案的,方案名叫Group replication 官方多主方案,基于Corosync实现

主从延时问题

原因:一般都会做读写分离,其实从库压力反而比主库大/从库读写压力大非常容易导致延时。

解决方案:

  • 首先定位延时瓶颈
  • 如果是IO压力,可以通过升级硬件解决,比如替换SSD等
  • 如果IO和CPU都不是瓶颈,非常有可能是SQL单线程问题,解决方案可以考虑刚才提到的并行复制方案
  • 如果还有问题,可以考虑sharding拆分方案

提到延时不得不提到很坑人的Seconds behind master,使用过MySQL的应该很熟悉

这个值的源码里算法

long time_diff= ((long)(time(0) – mi->rli.last_master_timestamp) – mi->clock_diff_with_master);

Secondsbehindmaster来判断延时不可靠,在网络抖动或者一些特殊参数配置情况下,会造成这个值是0但其实延时很大了。通过heartbeat表插入时间戳这种机制判断延时是更靠谱的

复制注意点:

  • Binlog格式,建议都采用row格式,数据一致性更好
  • Replication filter应用

主从数据一致性问题:

  • row格式下的数据恢复问题

InnoDB优化

成熟开源事务存储引擎,支持ACID,支持事务四个隔离级别,更好的数据安全性,高性能高并发,MVCC,细粒度锁,支持O_DIRECT。

主要优化参数:

  • innodbfileper_table =1
  • innodbbufferpool_size,根据数据量和内存合理设置
  • innodbflushlog_attrxcommit= 0 1 2
  • innodblogfile_size,可以设置大一些
  • innodbpagesize
  • Innodbflushmethod = o_direct
  • innodbundodirectory 放到高速设备(5.6+)
  • innodbbufferpool_dump
  • atshutdown ,bufferpool dump (5.6+)

上图是5.5 4G的redo log和5.6 设置大于4G redo log文件性能对比,可以看到稳定性更好了。innodblogfile_size设置还是很有意义的

InnoDB比较好的特性:

  • Bufferpool预热和动态调整大小,动态调整大小需要5.7支持
  • Page size自定义调整,适应目前硬件
  • InnoDB压缩,大大降低数据容量,一般可以压缩50%,节省存储空间和IO,用CPU换空间
  • Transportable tablespaces,迁移ibd文件,用于快速单表恢复
  • Memcached API,full text,GIS等

InnoDB在SSD上的优化:

  • 在5.5以上,提高innodbwriteiothreads和innodbreadiothreads
  • innodbiocapacity需要调大
  • 日志文件和redo放到机械硬盘,undo放到SSD,建议这样,但必要性不大
  • atomic write,不需要Double Write Buffer
  • InnoDB压缩
  • 单机多实例

也要搞清楚InnoDB哪些文件是顺序读写,哪些是随机读写

随机读写:

  • datadir
  • innodbdata file_path
  • innodbundo directory

顺序读写:

  • innodbloggrouphomedir
  • log-bin

InnoDB VS MyISAM:

  • 数据安全性至关重要,InnoDB完胜,曾经遇到过一次90G的MyISAM表repair,花了两天时间,如果在线上几乎不可忍受
  • 并发度高
  • MySQL 5.5默认引擎改为InnoDB,标志着MyISAM时代的落幕

TokuDB:

  • 支持事务 ACID 特性,支持多版本控制(MVCC)
  • 基于Fractal Tree Index,非常适合写入密集场景
  • 高压缩比,原生支持Online DDL
  • 主流分支都支持,收费转开源 。目前可以和InnoDB媲美的存储引擎

目前主流使用TokuDB主要是看中了它的高压缩比,Tokudb有三种压缩方式:quicklz、zlib、lzma,压缩比依次更高。现在很多使用zabbix的后端数据表都采用的TokuDB,写入性能好,压缩比高。

下图是我之前做的测试对比和InnoDB

上图是sysbench测试的和InnoDB性能对比图,可以看到TokuDB在测试过程中写入稳定性是非常好的。

tokudb存在的问题:

  • 官方分支还没很好的支持
  • 热备方案问题,目前只有企业版才有
  • 还是有bug的,版本更新比较快,不建议在核心业务上用

比如我们之前遇到过一个问题:TokuDB的内部状态显示上一次完成的checkpoint时间是“Jul 17 12:04:11 2014”,距离当时发现现在都快5个月了,结果堆积了大量redo log不能删除,后来只能重启实例,结果重启还花了七八个小时

MySQL优化相关的case

Query cache,MySQL内置的查询加速缓存,理念是好的,但设计不够合理,有点out。

锁的粒度非常大MySQL 5.6默认已经关闭

When the query cache helps, it can help a lot. When it hurts, it can hurt a lot.明显前半句已经没有太大用处,在高并发下非常容易遇到瓶颈。

关于事务隔离级别 ,InnoDB默认隔离级别是可重复读级别,当然InnoDB虽然是设置的可重复读,但是也是解决了幻读的,建议改成读已提交级别,可以满足大多数场景需求,有利于更高的并发,修改transaction-isolation。

上图是一个比较经典的死锁case,有兴趣可以测试下

关于SSD

关于SSD,还是提一下吧。某知名大V说过“最近10年对数据库性能影响最大的是闪存”,稳定性和性能可靠性已经得到大规模验证,多块SATA SSD做Raid5,推荐使用。采用PCIe SSD,主流云平台都提供SSD云硬盘支持。

最后说一下大家关注的单表60亿记录问题,表里数据也是线上比较核心的。

先说下当时情况,表结构比较简单,都是bigint这种整型,索引比较多,应该有2-3个,单表行数60亿+,单表容量1.2TB左右,当然内部肯定是有碎片的。

形成原因:历史遗留问题,按照我们前面讲的开发规范,这个应该早拆分了,当然不拆有几个原因:

  1. 性能未遇到瓶颈 ,主要原因
  2. DBA比较“懒“
  3. 想看看InnoDB的极限,挑战一下。不过风险也是很大的,想想如果在一个1.2TB表上加个字段加个索引,那感觉绝对酸爽。还有就是单表恢复的问题,恢复时间不可控。

我们后续做的优化 ,采用了刚才提到的TokuDB,单表容量在InnoDB下1TB+,使用Tokudb的lzma压缩到80GB,压缩效果非常好。这样也解决了单表过大恢复时间问题,也支持online DDL,基本达到我们预期。

今天讲的主要针对MySQL本身优化和规范性质的东西,还有一些比较好的运维经验,希望大家能有所收获。今天这些内容是为后续数据库做平台化的基础。我今天分享就到这里,谢谢大家。

QA

Q1:use schema;select * from table; 和select * from schema.table;两种写法有什么不一样吗?会对主从同步有影响吗?

对于主从复制来说执行效率上差别不大,不过在使用replication filter时候这种情况需要小心,应该要使用ReplicateWildIgnoreTable这种参数,如果不使用带wildignore,第一种方式会有问题,过滤不起作用。

Q2:对于用于MySQL的ssd,测试方式和ssd的参数配置方面,有没有好的建议?主要针对ssd的配置哈

关于SATA SSD配置参数,建议使用Raid5,想更保险使用Raid50,更土豪使用Raid 10

上图是主要的参数优化,性能提升最大的是第一个修改调度算法的

Q3:数据库规范已制定好,如何保证开发人员必须按照规范来开发?

关于数据库规范实施问题,也是有两个方面吧,第一、定期给开发培训开发规范,让开发能更了解。第二、还是在流程上规范,比如把我们日常通用的建表和字段策略固化到程序,做成自动化审核系统。这两方面结合 效果会比较好。

Q4:如何最大限度提高innodb的命中率?

这个问题前提是你的数据要有热点,读写热点要有交集,否则命中率很难提高。在有热点的前提下,也要求你的你的内存要足够大,能够存更多的热点数据。尽量不要做一些可能污染bufferpool的操作,比如全表扫描这种。

Q5:主从复制的情况下,如果有CAS这样的需求,是不是只能强制连主库?因为有延迟的存在,如果读写不在一起的话,会有脏数据。

如果有CAS需求,确实还是直接读主库好一些,因为异步复制还是会有延迟的。只要SQL优化的比较好,读写都在主库也是没什么问题的。

Q6:关于开发规范,是否有必要买国标?

这个国标是什么东西,不太了解。不过从字面看,国标应该也是偏学术方面的,在具体工程实施时候未必能用好。

Q7:主从集群能不能再细化一点那?不知道这样问合适不?

看具体哪方面吧。主从集群每个小集群一般都是采用一主多从方式,每个小集群对应特定的一组业务。然后监控备份和HA都是在每个小集群实现。

Q8:如何跟踪数据库table某个字段值发生变化?

追踪字段值变化可以通过分析row格式binlog好一些。比如以前同事就是通过自己开发的工具来解析row格式binlog,跟踪数据行变化。

Q9:对超大表水平拆分,在使用MySQL中间件方面有什么建议和经验分享?

对于超大表水平拆分,在中间件上经验不是很多,早期人肉搞过几次。也使用过自己研发的数据库中间件,不过线上应用的规模不大。关于目前众多的开源中间件里,360的atlas是目前还不错的,他们公司内部应用的比较多。

Q10:我们用的MySQL proxy做读负载,但是少量数据压力下并没有负载,请问有这回事吗?

少量数据压力下,并没有负载 ,这个没测试过,不好评价

Q11:对于binlog格式,为什么只推荐row,而不用网上大部分文章推荐的Mix ?

这个主要是考虑数据复制的可靠性,row更好。mixed含义是指如果有一些容易导致主从不一致的SQL ,比如包含UUID函数的这种,转换为row。既然要革命,就搞的彻底一些。这种mix的中间状态最坑人了。

Q12: 读写分离,一般是在程序里做,还是用proxy ,用proxy的话一般用哪个?

这个还是独立写程序好一些,与程序解耦方便后期维护。proxy国内目前开源的比较多,选择也要慎重。

Q13: 我想问一下关于mysql线程池相关的问题,什么情况下适合使用线程池,相关的参数应该如何配置,老师有这方面的最佳实践没有?

线程池这个我也没测试过。从原理上来说,短链接更适合用线程池方式,减少建立连接的消耗。这个方面的最佳配置,我还没测试过,后面测试有进展可以再聊聊。

Q14: 误删数据这种,数据恢复流程是怎么样的(从库也被同步删除的情况)?

看你删除数据的情况,如果只是一张表,单表在几GB或几十GB。如果能有延时备份,对于数据恢复速度是很有好处的。恢复流程可以参考我刚才分享的部分。目前的MySQL数据恢复方案主要还是基于备份来恢复 ,可见备份的重要性。比如我今天下午15点删除了线上一张表,该如何恢复呢。首先确认删除语句,然后用备份扩容实例启动,假设备份时间点是凌晨3点。就还需要把凌晨3点到现在关于这个表的binlog导出来,然后应用到新扩容的实例上。确认好恢复的时间点,然后把删除表的数据导出来应用到线上。

Q15: 关于备份,binlog备份自然不用说了,物理备份有很多方式,有没有推荐的一种,逻辑备份在量大的时候恢复速度比较慢,一般用在什么场景?

物理备份采用xtrabackup热备方案比较好。逻辑备份一般用在单表恢复效果会非常好。比如你删了一个2G表,但你总数据量2T,用物理备份就会要慢了,逻辑备份就非常有用了。

想和群内专家继续交流MySQL相关技术,请关注公众号后,回复arch,申请进群。

本文策划 庆丰@微博, 内容由王杰编辑,刘伟@途牛、陈刚@北京智识 校对与发布,其他多位志愿者对本文亦有贡献。读者可以通过搜索“ArchNotes”或长按下面图片,关注“高可用架构”公众号,查看更多架构方面内容,获取通往架构师之路的宝贵经验。转载请注明来自“高可用架构(ArchNotes)”公众号,敬请包含二维码!

ArkGameFrame游戏服务器解决方案

Github地址