标签 redis 下的文章

Redis持久化

Redis提供了不同级别的持久化方式:

  • RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
  • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
  • 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
  • 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:

- 阅读剩余部分 -

Dynomite 简介

Dynomite是NetFlix对亚马逊分布式引擎Dynamo的一个开源通用实现，它不仅支持基于内存K/V数据库,
还支持持久化的MySQL、BerkeleyDb、LevelDb等数据库，并具有简单、高效、支持跨数据中心的数据复制功能等优点。
Dynomite的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能。目前，Dynomite已经实现了对Redis和Memcached的支持。

Dynomite 安装配置

Build

从源代码构建Dynomite并启用调试日志,禁用assertions：

$ git clone git@github.com:Netflix/dynomite.git
$ cd dynomite
$ autoreconf -fvi
$ ./configure --enable-debug=yes    // 开发环境需要，生产环境不需要
$ make
$ src/dynomite -h

- 阅读剩余部分 -

简介和概述

Netflix长期以来一直是微服务模式的倡导者。该模型提供更高的可用性，故障恢复能力和松耦合。这种架构的缺点是潜在的用户体验。每当客户加载主页或开始流式传输电影时，都会有许多微服务完成该请求。这些微服务中的大多数使用某种有状态的系统来存储和提供数据。几毫秒可以快速加起来，并产生多秒的响应时间。

Netflix的云数据库工程团队一直在寻找方法，从应用程序的数据库响应时间中减少毫秒，同时保持我们的本地高可用性和多数据中心高可用性的目标。考虑到这个目标，我们创建了Dynomite。

受Dynamo白皮书以及Apache Cassandra的经验启发，Dynomite是一个分片和复制层。Dynomite可以将现有的非分布式数据存储（如Redis或Memcached）制作成完全分布式的多数据中心复制数据存储。

服务器架构

动机

在开源世界中，有各种单服务器数据存储解决方案，例如Memcached，Redis，BerkeleyDb，LevelDb，Mysql（数据存储）。这些单服务器数据存储的可用性故事通常最终会成为主从设置。一旦流量需求超过这个设置，下一个合乎逻辑的进程就是引入分片。大多数人会同意这种设置不是微不足道的。而且，管理来自不同分片的数据对于应用程序开发人员来说也是一项挑战。

- 阅读剩余部分 -

Redis 是基于内存的 Key Value 的 NoSql 数据库，由于其高性能，高可用，支持分布式集群的优点被广泛应用于缓存的业务场景。本篇文章就来了解下Redis缓存机制及内存淘汰策略。

如何使用缓存？

我们先来插入一个最简单的key

127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379>

OK, 插入成功。我们再来设置一下ke 的过期时间, redis有4个命令来设置过期时间：

expire <key> <ttl>：            // 将 key 的生存时间设置为 ttl 秒
pexpire <key> <ttl>：           // 将 key 的生存时间设置为 ttl 毫秒
expireat <key> <timestamp>：    // 将 key 的过期时间设置为 timestamp 所指定的秒数时间戳
pexpireat <key> <ttl>：         // 将 key 的过期时间设置为 timestamp 所指定的毫秒数时间戳

- 阅读剩余部分 -