使用Redis需要注意的数据安全问题
2017-10-20 19:46
549 查看
一、Redis宕机后的数据丢失问题
Redis会定期将内存中的数据同步到磁盘,这是我们大家都知道。而且是写数据越频繁同步的也就越频繁,这是在Redis配置文件中可配置的。
一般来说,宕机后可能丢失小量数据是在所难免的。可如果宕机后重启发现丢失大量数据这就不正常了,查了些资料,受益非浅。
Redis的数据回写机制分同步和异步两种:
1、同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据量大的情况下会导致系统假死很长时间,这个情况下对Redis的访问通常也会得不到响应,所以一般不是推荐的。
2、异步回写即BGSAVE命令,主进程fork出一个新进程后,复制自身并通过这个新的进程回写磁盘,回写结束后新进程自行关闭。由于这样做不需要主进程阻塞,系统不会假死,一般默认会采用这个方法。
个人感觉方法2采用fork主进程的方式有些拙劣,但似乎是唯一的方法。内存中的热数据随时可能修改,要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像,这样主进程上就不需要冻结,只要子进程上操作就可以了。
在小内存的进程上做一个fork,不需要太多资源。但当这个进程的内存空间以G为单位时,fork就成为一件很恐怖的操作。如果是在一个有16G内存配置的主机上fork出一个13G内存的进程呢?如果swap有8G,那么肯定会报内存无法分配的,这样数据就无法回写进磁盘。如果这个主机宕机了,那么丢失的数据就不是一点点了。而且越是改动频繁的主机上fork也越频繁,fork一个大数据进程的操作所花费的代价也不容忽视,还要考虑物理内存与swap的数据交换所造成的消耗。
所以在使用Redis时要保证数据量 小于 物理内存的一半,个人这么认为。
二、把Redis当缓存服务来使用
看过很多文章,都拿Redis和Memcached来比较使用。刚开始也觉得Redis可以代替Memcached。可后来细想后发现有严重问题。
如果Memcached服务器宕机了,那么服务器重启后,Memcached里所缓存的数据也就被清空了。再有数据访问时会先从关系型数据库中查询出来后,往Memcache存一份。让下一次同样的数据访问可以命中Memcached。
而Redis不仅会将数据缓存在内存中,也会将数据回写进磁盘。那么如果Redis服务器宕机了,宕机后关系型数据库中的数据被更新过了。然后重启Redis服务器,此时Redis服务器里的数据和关系型数据库中的数据就可能不一致了。除非重启Redis后立即清空其中做为缓存的数据。
当然,也可以使用主从模式的Redis集群来降低此类风险。如果宕掉的是从服务器那不会出现上述问题,但如果宕掉的是主服务器呢,问题则依旧。
因此我个人认为用Redis来替代Memcached是不安全的。
Redis会定期将内存中的数据同步到磁盘,这是我们大家都知道。而且是写数据越频繁同步的也就越频繁,这是在Redis配置文件中可配置的。
一般来说,宕机后可能丢失小量数据是在所难免的。可如果宕机后重启发现丢失大量数据这就不正常了,查了些资料,受益非浅。
Redis的数据回写机制分同步和异步两种:
1、同步回写即SAVE命令,主进程直接向磁盘回写数据。在数据量大的情况下会导致系统假死很长时间,这个情况下对Redis的访问通常也会得不到响应,所以一般不是推荐的。
2、异步回写即BGSAVE命令,主进程fork出一个新进程后,复制自身并通过这个新的进程回写磁盘,回写结束后新进程自行关闭。由于这样做不需要主进程阻塞,系统不会假死,一般默认会采用这个方法。
个人感觉方法2采用fork主进程的方式有些拙劣,但似乎是唯一的方法。内存中的热数据随时可能修改,要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像,这样主进程上就不需要冻结,只要子进程上操作就可以了。
在小内存的进程上做一个fork,不需要太多资源。但当这个进程的内存空间以G为单位时,fork就成为一件很恐怖的操作。如果是在一个有16G内存配置的主机上fork出一个13G内存的进程呢?如果swap有8G,那么肯定会报内存无法分配的,这样数据就无法回写进磁盘。如果这个主机宕机了,那么丢失的数据就不是一点点了。而且越是改动频繁的主机上fork也越频繁,fork一个大数据进程的操作所花费的代价也不容忽视,还要考虑物理内存与swap的数据交换所造成的消耗。
所以在使用Redis时要保证数据量 小于 物理内存的一半,个人这么认为。
二、把Redis当缓存服务来使用
看过很多文章,都拿Redis和Memcached来比较使用。刚开始也觉得Redis可以代替Memcached。可后来细想后发现有严重问题。
如果Memcached服务器宕机了,那么服务器重启后,Memcached里所缓存的数据也就被清空了。再有数据访问时会先从关系型数据库中查询出来后,往Memcache存一份。让下一次同样的数据访问可以命中Memcached。
而Redis不仅会将数据缓存在内存中,也会将数据回写进磁盘。那么如果Redis服务器宕机了,宕机后关系型数据库中的数据被更新过了。然后重启Redis服务器,此时Redis服务器里的数据和关系型数据库中的数据就可能不一致了。除非重启Redis后立即清空其中做为缓存的数据。
当然,也可以使用主从模式的Redis集群来降低此类风险。如果宕掉的是从服务器那不会出现上述问题,但如果宕掉的是主服务器呢,问题则依旧。
因此我个人认为用Redis来替代Memcached是不安全的。
相关文章推荐
- ~ 使用redis缓存数据需要注意的问题以及个人的一些思考和理解
- .NET中静态变量的使用需要注意线程安全问题
- 使用scribe来收集数据需要注意的问题
- 使用redis缓存数据需要注意的问题以及个人的一些思考和理解
- 使用SQLite附加(ATTACH)数据库时,需要注意数据文件编码的问题
- PHP使用redis安装时需要注意的问题
- 使用redis缓存数据需要注意的问题以及个人的一些思考和理解
- 使用分区删除数据需要注意的问题
- 使用redis缓存数据需要注意的问题以及个人的一些思考和理解
- 在使用微软提供的安全模版(安全策略)时需要注意的安全问题
- Oracle判断数据是否存在(使用游标判断需要注意的问题)
- 汇总使用Redis应该注意数据安全
- •在使用微软提供的安全模版(安全策略)时需要注意的安全问题-(2013/09/18)
- 调试使用了函数模块的程序时需要注意的一个小问题
- vs.net中使用SuperMap需要注意的问题[转载]
- 调试使用了函数模块的程序时需要注意的一个小问题
- 使用UL 列表结构建立横向导航栏需要注意的问题
- SQL Server数据导入、导出需要注意的问题
- 使用VS.NET需要注意的问题
- 使用异常时需要注意的一些问题(转)