数据库并发数
mysql的最大连接数默认是100, 这个数值对于并发连接很多的数据库应用是远远不够的，当连接请求大于默认连接数后，就会出现无法连接数据库的错误，因此我们需要把它适当调大一些。 调节方法为： 1.linux服务器中：改my中国f中的值就行了 2.Windows服务器中（我用的）: 在文件“my.ini”中找到段 [mysqld],在其中添加一行 max_connections=200 ### 200可以更改为想设置成的值. 然后重启"mysql"服务。 /mysqladmin所在路径/mysqladmin -uroot -p variables 输入root数据库账号的密码后可看到 | max_connections | 1000 | 其他需注意的： 在编程时，由于用mysql语句调用数据库时，在每次之执行语句前，会做一个临时的变量用来打开数据库，所以你在使用mysql语句的时候，记得在每次调用完mysql之后就关闭mysql临时变量。 另外对于访问量大的，可以考虑直接写到文本中，根据预测的访问量，先定义假若是100个文件文件名依次为1.txt,2.txt...100.txt。需要的时候，再对所有文本文件中的数据进行分析，再导入数据库
B. 如何处理数据库并发问题
想要知道如何处理数据并发，自然需要先了解数据并发。
什么是数据并发操作呢？
就是同一时间内，不同的线程同时对一条数据进行读写操作。
在互联网时代，一个系统常常有很多人在使用，因此就可能出现高并发的现象，也就是不同的用户同时对一条数据进行操作，如果没有有效的处理，自然就会出现数据的异常。而最常见的一种数据并发的场景就是电商中的秒杀，成千上万个用户对在极端的时间内，抢购一个商品。针对这种场景，商品的库存就是一个需要控制的数据，而多个用户对在同一时间对库存进行重写，一个不小心就可能出现超卖的情况。
针对这种情况，我们如何有效的处理数据并发呢？
第一种方案、数据库锁
从锁的基本属性来说，可以分为两种：一种是共享锁（S），一种是排它锁（X）。在MySQL的数据库中，是有四种隔离级别的，会在读写的时候，自动的使用这两种锁，防止数据出现混乱。
这四种隔离级别分别是：
读未提交（Read Uncommitted）
读提交（Read Committed）
可重复读（Repeated Read）
串行化（Serializable）
当然，不同的隔离级别，效率也是不同的，对于数据的一致性保证也就有不同的结果。而这些可能出现的又有哪些呢？
脏读（dirty read）
当事务与事务之间没有任何隔离的时候，就可能会出现脏读。例如：商家想看看所有的订单有哪些，这时，用户A提交了一个订单，但事务还没提交，商家却看到了这个订单。而这时就会出现一种问题，当商家去操作这个订单时，可能用户A的订单由于部分问题，导致数据回滚，事务没有提交，这时商家的操作就会失去目标。
不可重复读（unrepeatable read）
一个事务中，两次读操作出来的同一条数据值不同，就是不可重复读。
例如：我们有一个事务A，需要去查询一下商品库存，然后做扣减，这时，事务B操作了这个商品，扣减了一部分库存，当事务A再次去查询商品库存的时候，发现这一次的结果和上次不同了，这就是不可重复读。
幻读（phantom problem）
一个事务中，两次读操作出来的结果集不同，就是幻读。
例如：一个事务A，去查询现在已经支付的订单有哪些，得到了一个结果集。这时，事务B新提交了一个订单，当事务A再次去查询时，就会出现，两次得到的结果集不同的情况，也就是幻读了。
那针对这些结果，不同的隔离级别可以干什么呢？
“读未提（Read Uncommitted）”能预防啥？啥都预防不了。
“读提交（Read Committed）”能预防啥？使用“快照读（Snapshot Read）”方式，避免“脏读”，但是可能出现“不可重复读”和“幻读”。
“可重复读（Repeated Red）”能预防啥？使用“快照读（Snapshot Read）”方式，锁住被读取记录，避免出现“脏读”、“不可重复读”，但是可能出现“幻读”。
“串行化（Serializable）”能预防啥？有效避免“脏读”、“不可重复读”、“幻读”，不过运行效率奇差。
好了，锁说完了，但是，我们的数据库锁，并不能有效的解决并发的问题，只是尽可能保证数据的一致性，当并发量特别大时，数据库还是容易扛不住。那解决数据并发的另一个手段就是，尽可能的提高处理的速度。
因为数据的IO要提升难度比较大，那么通过其他的方式，对数据进行处理，减少数据库的IO，就是提高并发能力的有效手段了。
最有效的一种方式就是：缓存
想要减少并发出现的概率，那么读写的效率越高，读写的执行时间越短，自然数据并发的可能性就变小了，并发性能也有提高了。
还是用刚才的秒杀举例，我们为的就是保证库存的数据不出错，卖出一个商品，减一个库存，那么，我们就可以将库存放在内存中进行处理。这样，就能够保证库存有序的及时扣减，并且不出现问题。这样，我们的数据库的写操作也变少了，执行效率也就大大提高了。
当然，常用的分布式缓存方式有：Redis和Memcache，Redis可以持久化到硬盘，而Memcache不行，应该怎么选择，就看具体的使用场景了。
当然，缓存毕竟使用的范围有限，很多的数据我们还是必须持久化到硬盘中，那我们就需要提高数据库的IO能力，这样避免一个线程执行时间太长，造成线程的阻塞。
那么，读写分离就是另一种有效的方式了
当我们的写成为了瓶颈的时候，读写分离就是一种可以选择的方式了。
我们的读库就只需要执行读，写库就只需要执行写，把读的压力从主库中分离出去，让主库的资源只是用来保证写的效率，从而提高写操作的性能。
C. 什么是并发数
并发数，计算机网络术语，是指同时访问服务器站点的连接数。
由于虚拟主机是建立在每台服务器多用户的基础上的，也就是多个用户共同使用一台服务器。为了避免同一台服务器上的某一个用户的IIS链接人数过多或占用服务器资源过多而影响其它用户的正常使用。
所以，目前所有虚拟空间提供商都对单个用户的IIS链接数，流量及服务器进程占用CPU的比率进行了相应的限制。 当某一个用户的站点超出了服务器上的设制后，访问站点时就会出现服务器忙，或目前访问该站点的人数过多，超出了WEB的处理能力等相关错误提示。
(3)数据库并发数扩展阅读：
并发连接数是衡量防火墙性能的一个重要指标。在市面上常见防火墙设备的说明书中大家可以看到，从低端设备的500、1000个并发连接，一直到高端设备的数万、数十万并发连接，存在着好几个数量级的差异。
在我们用电脑工作时，打开的一个窗口或一个Web页面，我们也可以把它叫做一个“会话”，扩展到一个局域网里面，所有用户要通过防火墙上网，要打开很多个窗口或Web页面发（即会话），那么，这个防火墙，所能处理的最大会话数量，就是“并发连接数”。
检查您的网站是否存在比较大的图片、FLASH、音乐、电影等文件，例如：某一个站点的访问用户并不是很多，IIS链接数也可能只有几十个，但是他在网页中使用了比较大的的FLASH或图片（如超过300K），以增强网页效果。
结果就可能会出现不能访问的情况，原因是该站点的流量（带宽）使用量超限，所以建议网页上尽量使用较小的文件，这样即能避免流量超限，也能增加客户端的下载速度，给客户更好的感觉！
最后请注意：服务器对于某一个链接的默认超时时间一般为15--20分钟，也就是当访问用户访问你的网页并关闭后，一般需要15--20分钟，服务器才从其内存中将其清除，视为无效链接！
D. access数据库并发连接数
是指程序链接AC数据库的并发为255.
网站的并发数叫IIS并发.
E. 如何增加mysql数据库并发数
现象
Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.
猜想
猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.
验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.
检查环境
猜想失败, 回到常规的环境检查:
MySQL error log 未见异常.
syslog 未见异常.
tcpmp 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.
自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响
检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.
通过strace检查MySQL, 发现accept()调用确实没有感知到新连接.
Client 向 Server 发起连接请求, 发送SYN.
Server 预留连接资源, 向 Client 回复SYN-ACK.
Client 向 Server 回复ACK.
Server 收到 ACK, 连接建立.
在业务层上, Client和Server间进行通讯.
Client 向 Server 发起连接请求, 发送SYN.
Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.
Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).
Server 验证签名, 分配连接资源, 连接建立.
在业务层上, Client和Server间进行通讯.
从Client的视角, 连接已经建立.
从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)
若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误
若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.
- Some of these packets get lost because some buffer somewhere overflows.
probe kernel.function("cookie_v4_check").return
{
source_port = @cast($skb->head + $skb->transport_header, "struct tcphdr")->source
printf("source=%d, return=%d ",readable_port(source_port), $return)
}
function readable_port(port) {
return (port & ((1<<9)-1)) << 8 | (port >> 8)
}
- static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk->sk_ack_backlog > sk- >sk_max_ack_backlog;}
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. ",
proto, ntohs(tcp_hdr(skb)->dest), msg);
猜想2
怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:
怀疑是OS的原因, Google之, 得到参考文档:A TCP “stuck” connection mystery【http://www.evanjones.ca/tcp-stuck-connection-mystery.html】
分析
参考文档中的现象跟目前的状况很类似, 简述如下:
正常的TCP连接流程:
当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:
当启用SYN-cookie时, 第3步的ACK包因为某种原因丢失, 那么:
发生这种情况时:
TCP握手的第三步ACK包为什么丢失
参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:
我们可以通过Systemtap进一步探究原因.通过一个简单的脚本:
观察结果, 可以确认cookie_v4_check(syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.
之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):
恢复故障与日志的正关联
在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.
当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.
检查Linux源码:
可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.
粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.
解决方案
这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.
解决方案:
1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
2. 关闭syn_cookie. 有安全的人又要跳出来了.
3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.
有多个系统参数混合影响syn backlog长度, 参看【http://blog.bbelboer.com/2012/04/09/syn-cookies.html】
下图为精华总结