高并发系统的一些处理策略
2017-11-29 11:47
337 查看
高并发系统的一些处理策略:
服务器配置
数据库设计以及优化
缓存
数据一致性处理
服务器配置:
集群的环境,每个主机选择apahe 还是nginx,nignx的并发性好。nginx和apche区别 以及服务器的配置,例如缓存大小等
根据实际情况,可能对于图像比较多的情况,单独配置nginx服务器,作为图像服务器。在实习中使用的是七牛家的云存储单独作为图片存储,将有关车辆的上传图片全部放在上面。
数据库设计以及优化
(1)表的设计:
存储引擎:innodb还是 myisam? innodb支持事务外键,可以在崩溃时恢复(事务中redo日志实现),myisam不支持;存放数据的方式不同:myisam将表的结构frm 数据myd索引myi存在数据库目标中;innodb只在数据库目标文件中存在表的结构;索引采用B+树,myisam索引叶结点保存的是指针,指向数据,innodb存的就是数据;myisam占用空间小,在读的业务比较多的情况下采用myisam比较好。
字段的设置: 尽量使用短的字段,提高效率,建立索引也能减少资源浪费; 整型类型,比字符类型比较快;varchar 和 char不定长(节约空间)和定长(查询快)选用;索引字段:该字段进行不同的比较多,字段值不易过长。
合理选择数据的冗余:可以根据实际情况,不满足三范式:设置冗余字段,可以减少客户的处理,满足三范式,表之间的关系比较清晰,但是因为有外键什么的,多表关联可能性能降低,加大了用户的编程难度。
索引优化:别人整理的很好
(2)分库分表
针对大表,可以根据实际情况垂直分表或者水平分表。
垂直分表:对于大表中的某些字段经常使用,可以分表;
水平分表:例如月份,将不同的月份的数据存在不同的表中。
(3)mysql集群的环境
读写分离:主要针对读操作比较多的情况下。读写分离别人的,很好
目的:给大型网站缓解查询压力
原理:服务器运行amobe服务,可以判断sql是写还是读操作。收到sql语句是写,服务器将写送到master mysql处理,利用mysql proxy机制然后同步到slave mysql;
当服务器是select时,服务器会根据负载均衡挑选出一个slave mysql,将select语句送到并处理。
缓存:
可以将一些不动的页面:页面静态化/部分页面静态化;
或者将一些数据存在memcache或者redis中,不用去查表
数据一致性处理
当多个进程同时操作同一个数据,会产生资源争抢,数据一致性的问题。
高并发情况下,涉及到写操作时,不可能直接操作数据库,大并发的连接会导致mysql请求会阻塞,比如大量的insert update 请求到,会直接导致无数的行锁和表锁,甚至最后堆积很多,从来触发too many connections 错误。
web服务器 nginx和apache连接的进程有限,cpu上下文进程切换也会增加额外的开销,所以响应一定快。
这时可以采用
高并发下的数据安全,防超发,以抢票系统为例:
(1)消息队列:
将票数资源存在redis中,将请求存入消息队列(redis下的list阻塞的,可以实现消息队列,还可以实现优先消息队列点击打开链接)中,依次处理。缺点 :这样会处理比较慢,等待时间比较长。
:对于读操作是否也进入队列,这个问题根据具体的场景,像12306应该是不在队列中或者是优先排在最前面的,因为只是读,要求块。
(2)加锁
常见的锁: 排它锁;乐观锁;悲观锁;
排他锁:在进行写时,禁止一切的读和写;
乐观锁:认为在写的时候,别人不在写,维护一个version号,等处理后对照version好,一致则对,否则回滚,操作不成功,
悲观锁:认为在写的时候,别人也在写。采用数据库提供的锁机制:在写操作的时(insert updata 等)myisam默认是锁表,innodb根据是否是主键,主键则行锁,否则表锁。读操作,innodb采用mvcc版本控制。
可以采用乐观锁+回滚:
采用悲观锁:
服务器配置
数据库设计以及优化
缓存
数据一致性处理
服务器配置:
集群的环境,每个主机选择apahe 还是nginx,nignx的并发性好。nginx和apche区别 以及服务器的配置,例如缓存大小等
根据实际情况,可能对于图像比较多的情况,单独配置nginx服务器,作为图像服务器。在实习中使用的是七牛家的云存储单独作为图片存储,将有关车辆的上传图片全部放在上面。
数据库设计以及优化
(1)表的设计:
存储引擎:innodb还是 myisam? innodb支持事务外键,可以在崩溃时恢复(事务中redo日志实现),myisam不支持;存放数据的方式不同:myisam将表的结构frm 数据myd索引myi存在数据库目标中;innodb只在数据库目标文件中存在表的结构;索引采用B+树,myisam索引叶结点保存的是指针,指向数据,innodb存的就是数据;myisam占用空间小,在读的业务比较多的情况下采用myisam比较好。
字段的设置: 尽量使用短的字段,提高效率,建立索引也能减少资源浪费; 整型类型,比字符类型比较快;varchar 和 char不定长(节约空间)和定长(查询快)选用;索引字段:该字段进行不同的比较多,字段值不易过长。
合理选择数据的冗余:可以根据实际情况,不满足三范式:设置冗余字段,可以减少客户的处理,满足三范式,表之间的关系比较清晰,但是因为有外键什么的,多表关联可能性能降低,加大了用户的编程难度。
索引优化:别人整理的很好
(2)分库分表
针对大表,可以根据实际情况垂直分表或者水平分表。
垂直分表:对于大表中的某些字段经常使用,可以分表;
水平分表:例如月份,将不同的月份的数据存在不同的表中。
(3)mysql集群的环境
读写分离:主要针对读操作比较多的情况下。读写分离别人的,很好
目的:给大型网站缓解查询压力
原理:服务器运行amobe服务,可以判断sql是写还是读操作。收到sql语句是写,服务器将写送到master mysql处理,利用mysql proxy机制然后同步到slave mysql;
当服务器是select时,服务器会根据负载均衡挑选出一个slave mysql,将select语句送到并处理。
缓存:
可以将一些不动的页面:页面静态化/部分页面静态化;
或者将一些数据存在memcache或者redis中,不用去查表
数据一致性处理
当多个进程同时操作同一个数据,会产生资源争抢,数据一致性的问题。
高并发情况下,涉及到写操作时,不可能直接操作数据库,大并发的连接会导致mysql请求会阻塞,比如大量的insert update 请求到,会直接导致无数的行锁和表锁,甚至最后堆积很多,从来触发too many connections 错误。
web服务器 nginx和apache连接的进程有限,cpu上下文进程切换也会增加额外的开销,所以响应一定快。
这时可以采用
高并发下的数据安全,防超发,以抢票系统为例:
(1)消息队列:
将票数资源存在redis中,将请求存入消息队列(redis下的list阻塞的,可以实现消息队列,还可以实现优先消息队列点击打开链接)中,依次处理。缺点 :这样会处理比较慢,等待时间比较长。
:对于读操作是否也进入队列,这个问题根据具体的场景,像12306应该是不在队列中或者是优先排在最前面的,因为只是读,要求块。
(2)加锁
常见的锁: 排它锁;乐观锁;悲观锁;
排他锁:在进行写时,禁止一切的读和写;
乐观锁:认为在写的时候,别人不在写,维护一个version号,等处理后对照version好,一致则对,否则回滚,操作不成功,
悲观锁:认为在写的时候,别人也在写。采用数据库提供的锁机制:在写操作的时(insert updata 等)myisam默认是锁表,innodb根据是否是主键,主键则行锁,否则表锁。读操作,innodb采用mvcc版本控制。
可以采用乐观锁+回滚:
采用悲观锁:
相关文章推荐
- 高并发&高可用系统应对策略的一些思考
- 高并发&高可用系统应对策略的一些思考
- Linux系统使用--ubuntu 16.04安装与下载KDE(kubuntu-desktop)以及相关并发意外状况的处理
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- SSH案例--商城系统一些异常处理
- 不远复 秒杀系统:并发队列 接口设计 并发请求数据安全处理
- 千万级并发下的 推送系统建设策略解析(二)
- Java 秒杀高并发系统的一些想法设计
- [离散时间信号处理学习笔记] 3. 一些基本的LTI系统
- 事务(业务事务/系统事务)并发策略选择
- unity3d 捕获系统日志,来处理一些问题
- 高并发处理系统的理解---数据一致性(还有一点问题)
- 大型高并发高负载web应用系统架构-数据库架构策略
- epoll 处理并发的一些想法
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的某集团支付系统架构分享
- 系统架构之高可用和高并发粗略处理方案
- 每秒处理10万高并发订单的乐视集团支付系统架构分享(转载)
- Android 消息处理系统 Handler的一些介绍
- Android 拍照以及一些常用的处理,例如将图片显示到相册(包含了安卓系统6.0以上调用相机的处理)