redis 安装配置及持久化详解

一、redis简介

二、redis安装

三、redis配置文件详解

四、redis持久化详解

1.redis 简介

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

总的来说，redis更像是NoSQL，因Redis将数据存储于内存中，所以redis运行速度比传统的数据库快的多的多，根据业界测试，优化较好的单台可支持数十万的并发。

2.redis 安装

官网下载最新稳定版本：http://redis.io/

最新稳定版本:redis-3.0.7.tar.gz 

#此版本支持集群

tar -xf redis-3.0.7.tar.gz 
cd redis-3.0.7
make

创建目录及拷贝所需文件

mkdir -p /usr/local/redis/{conf,bin}
cp *.conf /usr/local/redis/conf/
cp runtest* /usr/local/redis/
cp mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-sentinel redis-server redis-trib.rb /usr/local/redis/bin/

创建数据文件目录

mkdir -pv /data/redis/db

创建日志路径

mkdir /data/log/redis -pv

3.配置文件详解

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

daemonize yes
#redis 以独立守护模式进程

pidfile /var/run/redis.pid
#指定pid文件路径

port 6379
#指定redis运行的端口

tcp-backlog 511
#TCP 监听的最大容纳数量，在高并发的环境下，你需要把这个值调高以避免客户端连接缓慢的问题。Linux 内核会一声不响的把这个值缩小成 /proc/sys/net/core/somaxconn对应的值，所以你要修改这两个值才能达到你的预期。

# bind 127.0.0.1
#指定redis监听的地址，默认监听所有

# unixsocket /tmp/redis.sock
#指定redis在Linux下socket文件路径

timeout 0
#客户端空闲多少秒后断开连接；默认是 0 表示不断开。

tcp-keepalive 0
#如果设置为非零，则在与客户端缺乏通讯的时候使用 SO_KEEPALIVE 发送 tcp acks 给客户端。推荐一个合理的值就是60秒。

loglevel notice
#日志文件级别，提供debug，verbose，notice，warning四种日志级别。

logfile "/data/log/redis/redis.log"
#指定日志文件路径

databases 16
#指定数据库实例的数量，默认为16个，默认使用的数据库是DB 0。

#RDB持久化的相关规则
#-------------------------------
save 900 1
#900秒有一个key变化则写磁盘
save 300 10
#300秒有10个key变化，则写磁盘
save 60 10000
#60秒有10000个key变化，则写磁盘
#-------------------------------

stop-writes-on-bgsave-error yes
默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，否则就会没人注意到灾难的发生。如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。

rdbcompression yes
# 是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串，默认都设为 yes如果你希望保存子进程节省点 cpu ，你就设置它为 no ，不过这个数据集可能就会比较大。

rdbchecksum yes
#是否校验RDB文件

dbfilename dump.rdb
#RDB文件保存文件名

dir /data/redis/db
#DB文件保存路径RDB和AOF文件

# slaveof  
#开启redis主从复制设置

# masterauth 
#连接主服务器需要的认证密码

slave-serve-stale-data yes
# 当一个 slave 与 master 失去联系，或者复制正在进行的时候，slave 可能会有两种表现：
#1) 如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候
#2) 如果为 no ，在你执行除了 info he salveof 之外的其他命令时，slave 都将返回一个 "SYNC with master in progress" 的错误。

slave-read-only yes
#设置salve是否为只读模式， 2.6之后，redis默认slave都是read-only的。

repl-diskless-sync no
# 复制集同步策略：磁盘或者socket
# 新slave连接或者老slave重新连接时候不能只接收不同，得做一个全同步。需要一个新的RDB文件dump出来，然后从master传到slave。可以有两种情况：
# 1）基于硬盘（disk-backed）：master创建一个新进程dump RDB，完事儿之后由父进程（即主进程）增量传给slaves。
# 2）基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。
# 基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave。基于socket的话， 新slave来了后，得排队（如果超出了repl-diskless-sync-delay还没来），完事儿一个再进行下一个。
# 当用diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了。否则就可以一起传。
# disk较慢，并且网络较快的时候，可以用diskless。（默认用disk-based）

repl-diskless-sync-delay 5
#当启用无硬盘备份，服务器等待一段时间后才会通过套接字向从站传送RDB文件，这个等待时间是可配置的。这一点很重要，因为一旦传送开始，就不可能再为一个新到达的从站服务从站则要排队等待下一次RDB传送。因此服务器等待一段时间以期更多的从站到达。 延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。

# repl-ping-slave-period 10
#默认值10，指定slave定期ping master的周期；

# repl-timeout 60
#以下内容设置备份的超时时间： 
#1）从从站的角度，同步期间的批量传输的I/O 
#2）从站角度认为的主站超时（数据，ping） 
#3）主站角度认为的从站超时（REPLCONF ACK pings) 
#确认这些值比定义的repl-ping-slave-period要大，否则每次主站和从站之间通信低速时都会被检测为超时。

repl-disable-tcp-nodelay no
#同步之后是否禁用从站上的TCP_NODELAY？ 
#如果你选择yes，redis会使用较少量的TCP包和带宽向从站发送数据。但这会导致在从站增加一点数据的延时。linux内核默认配置情况下最多40毫秒的延时。 
#如果选择no，从站的数据延时不会那么多，但备份需要的带宽相对较多。 
#默认情况下我们将潜在因素优化，但在高负载情况下或者在主从站都跳的情况下，把它切换为yes是个好主意。


# repl-backlog-size 1mb
#设置备份的工作储备大小。工作储备是一个缓冲区，当从站断开一段时间的情况时，它替从站接收存储数据，因此当从站重连时，通常不需要完全备份，只需要一个部分同步就可以，#即把从站断开时错过的一部分数据接收。 
#工作储备越大，从站可以断开并稍后执行部分同步的断开时间就越长。 
#只要有一个从站连接，就会立刻分配一个工作储备。

# repl-backlog-ttl 3600
#主站有一段时间没有与从站连接，对应的工作储备就会自动释放。接下来这个选项用于配置释放前等待的秒数，秒数从断开的那一刻开始计算。 值为0表示不释放。

slave-priority 100
#从站优先级是可以从redis的INFO命令输出中查到的一个整数。当主站不能正常工作时，redis sentinel使用它来选择一个从站并将它提升为主站。 
#低优先级的从站被认为更适合于提升，因此如果有三个从站优先级分别是10， 100， 25，sentinel会选择优先级为10的从站，因为它的优先级最低。 
#然而优先级值为0的从站不能执行主站的角色，因此优先级为0的从站永远不会被redis sentinel提升。 
#默认优先级是100

# min-slaves-to-write 3
# min-slaves-max-lag 10
#主站可以停止接受写请求，当与它连接的从站少于N个，滞后少于M秒。 
#N个从站必须是在线状态。 
#延迟的秒数必须<=所定义的值，延迟秒数是从最后一次收到的来自从站的ping开始计算。ping通常是每秒一次。 
#这一选项并不保证N个备份都会接受写请求，但是会限制在指定秒数内由于从站数量不够导致的写操作丢失的情况。 
#如果想要至少3个从站且延迟少于10秒，以上配置
#设置某一个为0表示禁用这一功能。

# min-slaves-max-lag is set to 10.
#默认情况下default min-slaves-to-write设置为0（禁用）而min-slaves-max-lag设置为10。

# requirepass foobared
#多数情况下无需密码鉴别slave。同时，由于redis处理速度太快，所以爆破速率可达150K/S。10万/S。所以如果你要设置密码，必须设置超强的密码。

# rename-command CONFIG ""
# 命令重命名，在一个shared环境里，可以对危险的命令，比如CONFIG，进行重命名：也可以用空字符串，达到完全屏蔽此命令的目的。
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
# rename-command CONFIG ""
# 记录进AOF或者传给slave的重命名操作可能会引发问题哦~。

# maxclients 10000
设置最大client连接数。默认10000一万个。

# maxmemory 
#如果redis用内存超过了设置的限制，第一，开始用maxmemory-policy配置的策略往外删数据，如果配置成了noeviction。所有write都会拒绝，比如set，lpush等。所有读请求可以接受。主要用在把redis用在LRU缓存，或者用在一个内存吃紧又不能删除的策略上。如果你有slave，你应该把最大内存别设置的太大，留一些系统内存给slave output buffers（如果是noeviction策略，就无需这样设置了）

# 内存策略。
# volatile-lru ->用LRU删除设置了ttl的key
# allkeys-lru ->用LRU删除任何key
# volatile-random ->随机删除有ttl的key
# allkeys-random ->随机删除任何key
# volatile-ttl ->删除即将ttl到期的key
# noeviction ->不删，有write的时候报错

# maxmemory-policy noeviction
#默认值volatile-lru，指定清除策略，有上面几种

# maxmemory-samples 5
默认值3，LRU和最小TTL策略并非严谨的策略，而是大约估算的方式，因此可以选择取样值以便检查。

appendonly no
#是否开启AOF模式

appendfilename "appendonly.aof"
#指定AOF文件名

# appendfsync always
appendfsync everysec
# appendfsync no
#调用fsync()方式让操作系统写数据到磁盘上，数据同步方式，以上几种
#always 总是写，一旦key发生变化就写磁盘，会消耗大量的系统资源。
#appendfsync everysec 每秒写一次磁盘，比较安全。
# appendfsync no不调用fsync，由操作系统决定何时同步，比较高效。

no-appendfsync-on-rewrite no
#默认值no。当AOF fsync策略设置为always或everysec，后台保存进程会执行大量的I/O操作。某些linux配置下redis可能会阻塞过多的fsync()调用。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 自动重写AOF
# 当AOF文件大小到一定比例，就自动隐式调用BGREWRITEAOF
#过程：redis记住最后一次rewrite时aof文件大小（重启后没rewrite的话，就是启动时AOF文件的大小），如果现在AOF大小和上次的比例达到特定值就重写。也要指定最小AOF大小，防止到2倍：1M的时候也重写。
# 把percentage改成0，就是禁用重写。

aof-load-truncated yes
# AOF文件可能在尾部是不完整的（上次system关闭有问题，尤其是mount ext4文件系统时没有加上data=ordered选项。只会发生在os死时，redis自己死不会不完整）。那redis重启时load进内存的时候就有问题了。
# 发生的时候，可以选择redis启动报错，或者load尽量多正常的数据。
# 如果aof-load-truncated是yes，会自动发布一个log给客户端然后load（默认）。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。

lua-time-limit 5000
# 如果达到最大时间限制（毫秒），redis会记个log，然后返回error。
# 当一个脚本超过了最大时限。只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一个可以杀没有调write命令的东西。要是已经调用了write，只能用第二个命令杀。
# 设置成0或者负值，时限就无限。

# cluster-enabled yes
#是否打开集群功能在3.0以后的版本支持集群。

# cluster-config-file nodes-6379.conf
#指定集群配置文件

# cluster-node-timeout 15000
#RedisCluster采用quorum+心跳的机制。从节点的角度看，节点会定期给其他所有的节点发送Ping，cluster-node-timeout(可配置，秒级)时间内没有收到对方的回复，则单方面认为对端节点宕机，将该节点标为PFAIL状态。


# cluster-slave-validity-factor 10
#如果将该项设置为0，不管slave节点和master节点间失联多久都会一直尝试failover（设为正数，失联大于一定时间（factor*节点TimeOut），不再进行FailOver）。比如，如果节点的timeout设置为5秒，该项设置为10，如果master跟slave之间失联超过50秒，slave不会去failover它的master（意思是不会去把master设置为挂起状态，并取代它）。注意：任意非0数值都有可能导致当master挂掉又没有slave去failover它，这样redis集群不可用。在这种情况下只有原来那个master重新回到集群中才能让集群恢复工作。

# cluster-migration-barrier 1
#一个master可以拥有的最小slave数量。该项的作用是，当一个master没有任何slave的时候，某些有富余slave的master节点，可以自动的分一个slave给它。

# cluster-require-full-coverage yes
#如果该项设置为yes（默认就是yes）当一定比例的键空间没有被覆盖到（就是某一部分的哈希槽没了，有可能是暂时挂了）集群就停止处理任何查询炒作。如果该项设置为no，那么就算请求中只有一部分的键可以被查到，一样可以查询（但是有可能会查不全）

slowlog-log-slower-than 10000
#线程阻塞不能服务其他请求的时间长度。两个参数：第一个是时长（以微秒为单位！，是毫秒的千分之一。）。第二个是log的size，超过了，就会删除之前的log。
# 1000000是一秒。负值是所有请求都记log！下边是0.10S。100毫秒。

slowlog-max-len 128
# log长度的设置值是没限制。但是需要内存。

latency-monitor-threshold 0
# 用LATENCY打印redis实例在跑命令时的耗时图表。
# 只记录大于等于下边设置的值的操作。0的话，就是关闭监视。可以动态开启。直接运行CONFIG SET latency-monitor-threshold 

notify-keyspace-events ""
# 可以通知pub/sub客户端关于key空间的变化。http://redis.io/topics/notifications
# 比如如果开着开关。一个client进行了DEL操作在“foo”key上在database0上。两个消息将会发布通过 pub/sub
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
# 大部分人不需要这个功能，并且还需要一定开销，所以默认关闭。

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# hash结构存储，小数据量的用数组，大数据量用map（encoding保存结构信息）

list-max-ziplist-entries 512
list-max-ziplist-value 64
# 与hash类似，满足条件的list数组也会采用特殊的方式以节省空间。

set-max-intset-entries 512
# 默认值512，当set类型中的数据都是数值类型，并且set中整型元素的数量不超过指定值时，使用特殊的编码方式。

zset-max-ziplist-entries 128
zset-max-ziplist-value 64
#与hash和list类似。

hll-sparse-max-bytes 3000
#HyperLogLog 不懂。大于16000完全不可接受！当CPU很顶得住的话，给10000可以。默认给3000.

activerehashing yes
# Active rehashing 越多次的操作进入了正在进行rehash的table，越多的rehash步骤需要执行。如果redis是空闲的，那么rehash操作是永远没法停止的，越多的内存也被消耗了。
# 默认就用yes就行 了如果你想释放内存ASAP。

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
# client output buffer限制，可以用来强制关闭传输缓慢的客户端（比如redis pub的东西有比较慢的client无法及时sub）
# client-output-buffer-limit    
# class可以为以下：
#
# normal -> normal clients including MONITOR clients
# slave  -> slave clients
# pubsub -> clients subscribed to at least one pubsub channel or pattern
# 当hard限制到了会立即被关闭客户端。如果soft限制到了，会等soft秒。
# 比如硬限制是32m，soft是16m，10secs。到32m就立即断，或者在16m以上停止了10secs。
# 设置成0就是关闭。

hz 10
# redis内部调度（进行关闭timeout的客户端，删除过期key等等）频率，越大则调度频率越高。设置成100以上会对CPU造成大压力除非你对线上实时性要求很高。可以在1~500之间。

aof-rewrite-incremental-fsync yes
# 当child进程在rewrite AOF文件，如果这个选项是yes，那么这个file每32MB会写fsync()。这个是保证增量写硬盘而防止写硬盘时I/O突增。

3.1.配置文件示例

daemonize no
pidfile /var/run/redis.pid
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/data/log/redis/redis.log"
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /data/redis/db
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes 
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1024mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

3.2.启动服务

# /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf

查看服务

# ps -ef | grep redis
root     24596 23241  0 14:52 pts/1    00:00:00 /usr/local/redis/bin/redis-server *:6379                          
502      24646 21849  0 14:52 pts/2    00:00:00 grep redis

4.持久化说明

4.1.两种持久化说明

Redis 提供了多种不同级别的持久化方式：

（1）RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

（2）AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。Redis 还可以在后台对AOF 文件进行重写（rewrite），使得AOF 文件的体积不会超出保存数据集状态所需的实际大小。

（3）Redis 还可以同时使用AOF 持久化和RDB 持久化。在这种情况下，当Redis 重启时，它会优先使用

AOF 文件来还原数据集，因为AOF 文件保存的数据集通常比RDB 文件所保存的数据集更完整。

（4）你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

了解RDB 持久化和AOF 持久化之间的异同是非常重要的，以下几个小节将详细地介绍这这两种持久化功

能，并对它们的相同和不同之处进行说明。

4.2.RDB 的优缺点

4.2.1.RDB有点

（1）RDB 是一个非常紧凑（compact）的文件，它保存了Redis 在某个时间点上的数据集。这种文件非常适合用于进行备份：比如说，你可以在最近的24 小时内，每小时备份一次RDB 文件，并且在每个月的每一天，也备份一个RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

（2） RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊S3 中。

（3）RDB 可以最大化Redis 的性能：父进程在保存RDB 文件时唯一要做的就是fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O 操作。

（4）RDB 在恢复大数据集时的速度比AOF 的恢复速度要快。

4.2.2.RDB 的缺点

 （1）如果你需要尽量避免在服务器故障时丢失数据，那么RDB 不适合你。虽然Redis 允许你设置不同的保存点（save point）来控制保存RDB 文件的频率，但是，因为RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5 分钟才保存一次RDB 文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。

 （2）每次保存RDB 的时候，Redis 都要fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时，fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。虽然AOF 重写也需要进行fork() ，但无论AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

 4.3.AOF优缺点

 4.3.1.AOF优点

 （1） 使用AOF 持久化会让Redis 变得非常耐久（much more durable）：你可以设置不同的fsync 策略，比如无fsync ，每秒钟一次fsync ，或者每次执行写入命令时fsync 。AOF 的默认策略为每秒钟fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

（2） AOF 文件是一个只进行追加操作的日志文件（append only log），因此对AOF 文件的写入不需要进行seek ，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof 工具也可以轻易地修复这种问题。

（3）Redis 可以在AOF 文件体积变得过大时，自动地在后台对AOF 进行重写：重写后的新AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis 在创建新AOF文件的过程中，会继续将命令追加到现有的AOF 文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。而一旦新AOF 文件创建完毕，Redis 就会从旧AOF 文件切换到新AOF 文件，并开始对新AOF 文件进行追加操作。

（4）AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis 协议的格式保存，因此AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export）AOF 文件也非常简单：举个例子，如果你不小心执行了FLUSHALL 命令，但只要AOF 文件未被重写，那么只要停止服务器，移除AOF 文件末尾的FLUSHALL 命令，并重启Redis ，就可以将数据集恢复到FLUSHALL 执行之前的状态。

 4.3.2.AOF 缺点

 （1）对于相同的数据集来说，AOF 文件的体积通常要大于RDB 文件的体积。

 （2） 根据所使用的fsync 策略，AOF 的速度可能会慢于RDB 。在一般情况下，每秒fsync 的性能依然非常高，而关闭fsync 可以让AOF 的速度和RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

 （3） AOF 在过去曾经发生过这样的bug ：因为个别命令的原因，导致AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令BRPOPLPUSH 就曾经引起过这样的bug 。）测试套件里为这种情况添加了测试：它们会自动生成随机的、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种bug 在AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种bug 的。

总结：至于你想用哪种取决你的业务，是数据重要还是性能，如果为了安全，建议两者一起使用