怎样解决数据库高并发的问题
-
缓存式的Web应用程序架构
在web层和DB(数据库)层之间加一层cache层,主要目的:减少数据库读取负担,提高数据读取速度。cache存取的媒介是内存,可以考虑采用分布式的cache层,这样更容易破除内存容量的限制,同时增加了灵活性。 -
增加Redis缓存数据库:
-
增加数据库的索引
-
页面静态化
效率最高,消耗最小的就是纯静太化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最高效的方法。用户可以直接获取页面,不用像MVC结构走那么多流程,比较适用于页面信息大量被前台程序调用,但是更新频率很小的情况。 -
使用存储过程
处理一次请求需要多次访问数据库的操作,可以把操作整合到储存过程,这样只要一次数据库访问就可以了。 -
MySQL主从读写分离
当数据库的写压力增加,cache层(如Memcached)只能缓解数据库的读取压力。读写集中再一个数据库上让数据库不堪重负。使用主从复制技术(master—slave模式)来达到读写分离,以提高读写性能和读库的可扩展性。读写分离就是只在主服务器上写,只在从服务器上读,基本原则是让主数据库处理事务性查询,而从数据库处理select查询,数据库复制被用于把事务性查询(增删改)导致的改变更新同步到集群中的从数据库。
MySQL读写分离提升系统性能:
1.主从只负责各自的读和写,极大程度缓解X锁和S锁争用。
2.slave可以配置 MyISAM引擎,提升查询性能以及节约系统开销。
3.master直接写是并发的,slave通过主库发送来的binlog恢复数据是异步的。
4.slave可以单独设置一些参数来提升其读的性能。
5.增加冗余,提高可用性。
实现主从分离可以使用MySQL中间件如:Atlas -
分表分库
在cache层的高速缓存,MySQL的主从复制,读写分离的基础上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。采用Master-Slave复制模式的MySQL架构,只能对数据库的读进行扩展,而对数据的写操作还是集中在Master上。这时需要对数据库的吞吐能力进一步地扩展,以满足高并发访问与海量数据存储的需求。对于访问极为频繁且数据量巨大的单表来说,首先要做的是减少单表的记录条数,以便减少数据查询所需的时间,提高数据库的吞吐,这就是所谓的分表【水平拆分】。在分表之前,首先需要选择适当的分表策略(尽量避免分出来的多表关联查询),使得数据能够较为均衡地分布到多张表中,并且不影响正常的查询。
分表能够解决表单数据量过大带来的查询效率下降的问题,但是却无法给数据库的并发处理能力带来质的提升。面对高并发的读写方向,当数据库master服务器无法承载写操作压力时,不管如何扩展Slave服务器都是没有意义的,对数据库进行拆分,从而提高数据库写入能力,即分库【垂直拆分】
- 负载均衡集群
将大量的并发请求分担到多个处理字点,由于单个处理节点的故障不影响整个服务,负载均衡集群同时也实现了高可用性。
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
MySQL和Redis高可用性体现在哪些方面
- MySQL Replication 是MySQL官方提供的主从同步方案,用于将一个MySQL实列的数据,同步到另一个实列中。Replication为保证 数据安全做了重要的保证,也是现在运用最广的MySQL容灾方案。Replication用两个或以上的实列搭建了MySQL主从复制集群,提供单点写入,多点读取的服务,实现了读的scale out。
- Sentinel是Redis官方为集群提供的高可用解决方案。在实际项目中可以使用sentinel去做Redis自动故障转移,减少人工介入的工作量。另外sentinel也给客户端提供了监控消息的通知,这样客户端就可根据消息类型去判断服务器的状态,去做对应的适配操作。
- 下面是Sentinel主要功能列表:
Monitoring:Sentinel持续检查集群中的master、slave状态,判断是否存活。
Notification:在发现某个Redis实列死的情况下,Sentinel能通过API通知系统管理员或其他程序脚本。
Automatic failover:如果一个master挂掉后,sentinel立马启动故障转移,把某个slave提升为master。其他的slave重新配置指向新master。
Configuration provider:对于客户端来说sentinel通知是有效可信赖的。客户端会连接sentinel去请求当前master的地址,一旦发生故障sentinel会提供新地址给客户端。