阿里云数据库redis怎么配置

根据下面步骤创建适应业务需求的云数据库Redis版实例。

使用下列方法中任意一种打开购买页：

打开云数据库Redis版产品首页，单击立即购买。

说明 如果尚未登录阿里云账号，单击立即购买后需要先使用阿里云账号和密码登录。

登录Redis管理控制台，单击右上角的创建实例。

设置以下参数。

选择密码设置方式。

立即设置：在下方的输入密码区域设置密码。

稍后设置：创建实例后再修改密码。

设置实例名称、购买数量，如果创建包年包月实例，还需设置时长。

在确认订单页，阅读《云数据库KVStore版服务协议》，确认接受后在服务协议前的选框中单击勾选。

单击去开通。

因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。

接下来我们来安装Redis

1、先到Redis官网(redis.io)下载redis安装包

2、将其下载到我的/lamp目录下

3、解压并进入其目录

4、编译源程序

make

cd src

make install PREFIX=/usr/local/redis

5、将配置文件移动到redis目录

6、启动redis服务

7、默认情况，Redis不是在后台运行，我们需要把redis放在后台运行

vim /usr/local/redis/etc/redis.conf

将daemonize的值改为yes

8、客户端连接

/usr/local/redis/bin/redis-cli

9、停止redis实例

/usr/local/redis/bin/redis-cli shutdown

或者

pkill redis-server

10、让redis开机自启

vim /etc/rc.local

加入

/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis-conf

11、接下来我们看看/usr/local/redis/bin目录下的几个文件时什么

redis-benchmark：redis性能测试工具

redis-check-aof：检查aof日志的工具

redis-check-dump：检查rdb日志的工具

redis-cli：连接用的客户端

redis-server：redis服务进程

Redis的配置

daemonize：如需要在后台运行，把该项的值改为yes

pdifile：把pid文件放在/var/run/redis.pid，可以配置到其他地址

bind：指定redis只接收来自该IP的请求，如果不设置，那么将处理所有请求，在生产环节中最好设置该项

port：监听端口，默认为6379

timeout：设置客户端连接时的超时时间，单位为秒

loglevel：等级分为4级，debug，revbose，notice和warning。生产环境下一般开启notice

logfile：配置log文件地址，默认使用标准输出，即打印在命令行终端的端口上

database：设置数据库的个数，默认使用的数据库是0

save：设置redis进行数据库镜像的频率

rdbcompression：在进行镜像备份时，是否进行压缩

dbfilename：镜像备份文件的文件名

dir：数据库镜像备份的文件放置的路径

slaveof：设置该数据库为其他数据库的从数据库

masterauth：当主数据库连接需要密码验证时，在这里设定

requirepass：设置客户端连接后进行任何其他指定前需要使用的密码

maxclients：限制同时连接的客户端数量

maxmemory：设置redis能够使用的最大内存

appendonly：开启appendonly模式后，redis会把每一次所接收到的写 *** 作都追加到appendonly.aof文件中，当redis重新启动时，会从该文件恢复出之前的状态

appendfsync：设置appendonly.aof文件进行同步的频率

vm_enabled：是否开启虚拟内存支持

vm_swap_file：设置虚拟内存的交换文件的路径

vm_max_momery：设置开启虚拟内存后，redis将使用的最大物理内存的大小，默认为0

vm_page_size：设置虚拟内存页的大小

vm_pages：设置交换文件的总的page数量

vm_max_thrrads：设置vm IO同时使用的线程数量

redis作为一款优秀的NoSQL代表软件，正变得越来越流行，虽然Redis很容易就可以启动并使用，但是要想在线上用好它却也并非易事。redis的高可用和可扩展无论是自带的Redis Sentinel还是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，实际上客户端来做这些事情也并不合适，它会让维护变得特别困难。因此在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，可以完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy之前，已经有几款流行的redis代理，它们各具特色。接下来，我们就来比较以下代理：

简单来说，predixy既支持Redis Sentinel也支持Redis Cluster

作为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来我们就来做个简单的评测，测试平台及各代理具体的版本信息如下：

redis-server、各代理、redis-benchmark均在这一台机器上运行。

redis部署：

以下测试的结果中，横坐标为数据大小、纵坐标为qps或者毫秒。

这里单线程是指四款代理都运行在单线程下（下同），redis-benchmark默认并发50个客户端连接，每个连接每次发送一个命令收到响应后再发下一个命令。这是很多线上实际的场景。

在吞吐上，四款代理的性能排列的整齐有序，predixy大幅领先于另外三款代理，而twemproxy又以较大优势领先另外两个，剩下的两个codis在数据量小于512的时候稍稍领先cerberus，而当数据量大于512的时候，codis对cerberus的领先越来越大。整体上在数据量达到16KB时，由于redis-benchmark本身成为瓶颈，predixy和twemproxy的SET成绩差不多了。

在延时上，codis由于语言的问题，一直都大于另外三款代理，后续测试也一样。

在有些场景下，客户端可能在处理一个请求时可能需要发起多次redis请求，这时如果把多个redis请求pipeline一起请求的话，会大幅改善性能。本轮测试就来看看当客户端一次发送多个请求时我们各代理表现如何？Redis-benchmark依旧是并发50个连接，但是一次发送20个命令。

在吞吐上，redis-benchmark一次pipeline 20个命令后，各代理的吞吐量全都猛增。predixy更是一骑绝尘，遥遥领先另外三个，而最后看到在GET 4K数量据的时候predixy表现和其它代理差不多是因为对predixy来说，当数据量大于2K时redis-benchmark自身已经成为瓶颈。另外三款代理，在上轮测试中落后的cerberus在本轮测试一开始表现远好过twemproxy和codis，但cerberus还是存在随着数据量变大性能迅速降低的问题。twemproxy和codis在本轮测试中表现基本相当。

在时延上，codis固有的问题表现较差，另外三款在数据量较小时差别较小，而当数据量超过512时，predixy则表现出较明显的优势。

测完了单线程，现在我们开始多线程测试，由于twemproxy不支持多线程，因此twemproxy不参与多线程的测试。考虑到redis-benchmark本身是个单线程程序，在多线程代理下如果我们再测单个命令的性能，那redis-benchmark很可能就是瓶颈，则无法更明确的看出各代理的性能差异，因此我们直接测试pipeline，还跟上轮一样，50个并发连接，一次发送20个命令。

总体趋势和第二轮单线程pipeline测试一致，predixy在本轮测试中依旧取得了领先，不过在开始阶段cerberus和predixy遥遥领先于codis，cerberus和predixy差距不大。但是随着数据量的变大，cerberus再次显示出了性能急剧降低的问题，到1K以后甚至就比codis差了。

在功能的对比上，predixy相比另外三款代理更为全面，基本可以完全适用原生redis的使用场景。在性能上，predixy在各轮测试中都以较大优势领先。对各代理的总结如下：

---