6月
09
2012
5
11月
09
2011
0

Redis容灾策略

Redis利用内存发挥的高性能读写在很多场景下大有所为,但是Redis本身毕竟还是一个单机数据库,如果系统对其属于强依赖,那么还是必须做好必要的容灾,针对这个问题,有以下几种策略:

一、M/S切换

由于Redis是单机数据库,所以针对MySQL的一些容灾方案也能顺利适用,例如当Redis意外宕机,可以将请求马上切到备库,同时快速恢复数据。

二、AOF

Redis有两种持久化的方式,分别是SnapShotting和Append-Only File,其原理和特性可以参考《对redis数据持久化的一些想法》一文,总得来说,快照对性能影响更小,也只会备份需要的数据,但两次快照中间的数据是没法保证一定会持久化的。

相比之下AOF的粒度更细,持久化效果更好,类似于MySQL的BinLog,缺点是会损失一部分性能,而且会记录不必要的日志,这一点当系统运行时间很长时会特别突出,也许恢复所有数据本来只要1个小时,却可能要花100甚至1000小时去搞。

三、读取数据源直接恢复

这个方案是和业务场景相关的,由于之前某个项目中Redis起到了存放索引的作用,所以利用MySQL的数据可以容易地重新建立Redis的所有内容,这里可以临时搞一个Trigger,不断读MySQL写Redis,利用MySQL的顺序读和Redis高TPS的特性,实践中,可以在几分钟内重建上千万的数据量。

目前Redis在功能上通常仍用于Cache,如果需要保证HA的持久化存储,请考虑具体场景,此外也可以考虑是否可以使用原生分布式的memcached或升级硬件(如SSD、Fusion-IO)增强原有DB的性能。

Written by Hesey Wang in: 技术,数据库 |
4月
09
2011
0

QCon2011大会4月8日PPT学习总结

最近正在召开QCon北京2011大会,趁此机会学习了一部分QCon大会的PPT,大会的PPT可以在QCon大会官网下载:http://www.qconbeijing.com/schedule.html

主题:淘宝商品库优化实践

讲师:淘宝核心系统数据库组 余锋(褚霸)

在技术方案的着眼点上,讲师主要强调了:通过高性能硬件支持平台,充分利用Cache(这一点在之后的演讲中多次强调),充分考虑容灾性。同时讲师表示要大胆借助开源产品提高系统性能

在I/O能力的分配上,提高读能力的方式是零散读,提高IOPS,对于提高写能力采用了集中写,提高吞吐量

在Cache分配上,商品库除了采用MySQL的内部存储、虚拟内存以外,还利用了Facebook的Flashcache技术(在文件系统和设备驱动之间新增一次缓存层,实现对热门数据的缓存,一般用SSD作为介质的缓存,通过将传统硬盘上的热门数据缓存到SSD上,然后利用SSD优秀的读性能,来加速系统)。这个方法较之内存缓存,没有内存快,但是可用空间可以比内存大很多。此外还利用了RAID卡内部Cache。

对于系统调优的指导思想,重视理论结合实际,不靠主观猜测而是按实际效果做决定。“内存为王”,用加大内存提升系统性能(其实也是间接加大了缓存)。随机数据和顺序数据分离,随机数据采用Direct IO(优点是CPU占用率小,适用于缓存命中率较低的文件),顺序数据通过缓存读。在保证安全的前提下,一定要充分利用系统各级的Cache

在业务上优化掉复杂查询(类似天涯论坛的做法)。对于InnoDB,分配尽可能大的Buffer Pool,日志数据分开存储,减少锁对多核CPU的影响(减小锁的开销),适时清除InnoDB产生的日志Cache。 (more…)

Written by Hesey Wang in: 技术,数据库,架构 |
4月
09
2011
0

NoSQL简介

传统关系型数据库面临很多问题。

1、需要很高的实时插入性能:在高并发读写环境下,每秒上万次读请求勉强可以支撑,但是在每秒上万次写请求之下,硬盘I/O将无法承受。

2、需要海量数据存储能力的同时还需要非常快的查询检索速度:在一个表中存储数以亿计的记录后,使用SQL查询的效率是极为低下的。

3、需要将数据存储无缝扩展到整个集群:数据库的横向扩展比较困难,往往需要停机维护和数据迁移,不能像Web服务器那样简单地通过增加服务器数量来减轻负载。

针对高并发读写海量存储以及可扩展性三个方向,有不同的NoSQL解决方案,这里对每个方向分别简要介绍了Redis、MongoDB、Cassandra三款NoSQL数据库。 (more…)

Written by Hesey Wang in: 技术,数据库 |

©2006 - 2016 Hesey (舒)