189 8069 5689
现象
成都创新互联自2013年起，是专业互联网技术服务公司，拥有项目做网站、网站制作网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元江苏做网站,已为上家服务,为江苏各地企业和个人服务,联系电话:18980820575
Sysbench对MySQL进行压测, 并发数过大(5k)时, Sysbench建立连接的步骤会超时.
猜想
猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.
验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.
检查环境
猜想失败, 回到常规的环境检查:
MySQL error log 未见异常.
syslog 未见异常.
tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.
自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响
猜想2
怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:
检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.
通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.
怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【】
分析
参考文档中的现象跟目前的状况很类似, 简述如下:
正常的TCP连接流程:
Client 向 Server 发起连接请求, 发送SYN.
Server 预留连接资源, 向 Client 回复SYN-ACK.
Client 向 Server 回复ACK.
Server 收到 ACK, 连接建立.
在业务层上, Client和Server间进行通讯.
当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:
Client 向 Server 发起连接请求, 发送SYN.
Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.
Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).
Server 验证签名, 分配连接资源, 连接建立.
在业务层上, Client和Server间进行通讯.
当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:
从Client的视角, 连接已经建立.
从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)
发生这种情况时:
若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误
若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.
TCP握手的第三步ACK包为什么丢失
参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:
Some of these packets get lost because some buffer somewhere overflows.
我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:
probe kernel.function("cookie_v4_check").return
{
source_port = @cast($skb-head + $skb-transport_header, "struct tcphdr")-source
printf("source=%d, return=%d\n",readable_port(source_port), $return)
}
function readable_port(port) {
return (port ((19)-1)) 8 | (port 8)
}
观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.
之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):
static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk-sk_ack_backlog sk- sk_max_ack_backlog;}
恢复故障与日志的正关联
在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.
当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.
检查Linux源码:
if (!queue-synflood_warned
sysctl_tcp_syncookies != 2
xchg(queue-synflood_warned, 1) == 0)
pr_info("%s: Possible SYN flooding on port %d. %s.
Check SNMP counters.\n",
proto, ntohs(tcp_hdr(skb)-dest), msg);
可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.
粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.
解决方案
这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.
解决方案:
1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
2. 关闭syn_cookie. 有安全的人又要跳出来了.
3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.
有多个系统参数混合影响syn backlog长度, 参看【】
下图为精华总结
请点击输入图片描述
处理高并发的方法不止三种。
1：系统拆分
将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。
2：缓存，必须得用缓存
大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发，没问题的。所以可以考的虑考虑项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。
3：MQ(消息队列)，必须得用MQ
可能还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，那高并发绝对搞挂系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。
所以该用mysql还得用mysql，用MQ，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是可以的。
4：分库分表
可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。
5：读写分离
这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
大数据并发处理解决方案：
1、HTML静态化
效率最高、消耗最小的就是纯静态化的html页面，所以尽可能使网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，无法全部手动去挨个实现，于是出现了常见的信息发布系统CMS，像常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
2、图片服务器分离
对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现，如果服务器集群操作起来更方便，如果是独立的服务器，新手可能出现上传图片只能在服务器本地的情况下，可以在令一台服务器设置的IIS采用网络路径来实现图片服务器，即不用改变程序，又能提高性能，但对于服务器本身的IO处理性能是没有任何的改变。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是需要使用数据库集群或者库表散列。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
1、使用行级别锁，避免表级别或页级别锁
尽量使用支持行级别锁的存储引擎，如InnoDB;只在读操作显著多于写作的场景中(如数据仓库类的应用)使用表级别锁的存储引擎，如MyISAM;。
2、降低热巨锁(hot gaint lock)出现的可能性以尽可能避免全局互斥量
临界区(仅允许单一线程访问的资源)会严重降低MySQL系统并发性;InnoDB缓冲池(buffer pool)、数据字典等都是常见的临界区;幸运的是，新版本的InnoDB已经能够较好的运行于多核处理器，支持使用 innodb_buffer_pool_instances服务器变量建立多个缓冲池实例，每个缓冲池实例分别自我管理空闲列表、列表刷写、LRU以及其它跟缓冲池相关的数据结构，并通过各自的互斥锁进行保护。
3、并行运行多个I/O线程
通过innodb_io_capacity服务器变量等增加磁盘I/O线程的数量可以提高前端操作(如SELECT)的性能，不过，磁盘I/O线程的数量不应该超过磁盘的IOPS(7200RPM的单块硬件的IOPS数量一般为100个左右)。
此外，异步I/O也可以在一定程度上提高系统的并发能力，在Linux系统上，可以通过将MySQL的服务器变量innodb_use_native_aio的值设定为ON设定InnoDB可以使用Linux的异步I/O子系统。
4、并行后端任务
默认情况下，MySQL的清写(purge)操作(用于移除带删除标记的记录)由InnoDB的主线程完成，这可以降低内部资源竞争发生的概率，进而增强MySQL服务伸缩能力。不过，随着InnoDB内部各式各样的竞争越来越多，这种设置带来的性能优势已几乎不值一提，因此，生产环境中应该通过为innodb_purge_threads服务器变量设定为ON将主线程与清写线程分开运行。
5、单线程复制模型中的SQL线程是一个热区
在从服务器上并行运行多个SQL线程可有效提高MySQL从服务器性能，MySQL 5.6支持多线程复制(每库一个复制线程);
您好，MySQL高并发添加列的方法有多种，主要有以下几种：
1. 使用ALTER TABLE语句：使用ALTER TABLE语句可以在表中添加新的列，可以在表中添加多个列，也可以在表中添加多个列，但是在高并发的情况下，这种方法可能会导致表锁，影响性能。
2. 使用CREATE TABLE语句：使用CREATE TABLE语句可以在表中添加新的列，可以在表中添加多个列，这种方法可以避免表锁，但是在高并发的情况下，可能会导致数据不一致，所以不推荐使用。
3. 使用INSERT INTO语句：使用INSERT INTO语句可以在表中添加新的列，可以在表中添加多个列，这种方法可以避免表锁，也可以保证数据的一致性，但是在高并发的情况下，可能会导致性能下降，所以也不推荐使用。
4. 使用存储过程：使用存储过程可以在表中添加新的列，可以在表中添加多个列，这种方法可以避免表锁，也可以保证数据的一致性，而且在高并发的情况下，可以提高性能，所以是比较推荐使用的方法。