使用redis的原因 

1. 性能极高 : Redis能读的速度是110000次/s,写的速度是81000次/s 。(运行在内存中,所以速度超快) 

2.丰富的数据类型: Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。 

3.原子: Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。(这里并不是说事的原子性要理解好,假设事务中有3个操作,a操作执行成功,b操作执行失败,a操作并不会回滚,而是继续下去执行c操作) 

4.丰富的特性: Redis还支持 publish/subscribe, 通知, key 过期等等特性。(发布订阅功能,我用的较少,听说可以做推送功能)

下面介绍配置文件

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突增。

通常使用的启动方式有两种: 

./redis-server & 

这个直接启动,采用代码中的默认配置(并不读取默认配置文件), &跟什么mysql差不多,后台运行 

另一种是加载配置文件 

./redis-server ./redis.conf 

一般都是采用自己的port.conf配置文件进行启动,看个人喜好

这里发个链接介绍redis的基本命令,有兴趣的可以查阅 

redis命令大全

redis的高效率是因为运行在内存中,所以秒不了要提到他的持久化问题. 

redis的持久化有2个方面,根据自己的数据需求,可以采用不同的方法 

1.数据快照 

filesnapshotting 

　　默认redis是会以快照的形式将数据持久化到磁盘的（一个二进 制文件，xx.rdb) 

　　在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。 

　　当然我们也可以手动执行save或者bgsave（异步）做快照。 

　　工作原理简单介绍：当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write 

缺点：filesnapshotting方法在redis异常死掉时， 最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的

2.AOF, 

Appened-only file 

　　可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，可以选择三种不同的策略，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到 redis关闭前的最后时刻。

AOF的三种策略 

appendfsync ：appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全； 

appendfsync everysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据； 

appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。 

LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。 

因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。 

所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。 

LOG Rewrite的工作原理:同样用到了copy-on-write：首先redis会fork一个子进程；子进程将最新的AOF写入一个临时文件；父进程 增量的把内存中的最新执行的修改写入（这时仍写入旧的AOF，rewrite如果失败也是安全的）；当子进程完成rewrite临时文件后，父进程会收到 一个信号，并把之前内存中增量的修改写入临时文件末尾；这时redis将旧AOF文件重命名，临时文件重命名，开始向新的AOF中写入。

AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。(比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了)。为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。

因此,配置文件中有2个字段可以限制aof的无限制增长

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。  
auto-aof-rewrite-percentage 100  

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。  
auto-aof-rewrite-min-size 64mb

回到我们的c++服务器中的使用redis方法:(官方的hiredis库) 

贴下代码

int RedisDBMgr::Connect(redisContext*& connect, const char* host, unsigned int port, const char* pwd)
{
    do{
        if(connect != NULL)
        {
            redisFree(connect);
            connect = NULL;
        }

        struct timeval timeout = {5, 0};
        LOG_DEBUG("RedisDBMgr::Connect host=%s, port=%u", host, port);
        connect = redisConnectWithTimeout(host, port, timeout);
        if(connect == NULL)
        {
            LOG_ALERT("RedisDBMgr::Connect FAIL host=%s, port=%u", host, port);
            break;
        }

        if(connect->err != 0)
        {
            LOG_ALERT("RedisDBMgr::Connect FAIL errno=%d, err=%s", connect->err, connect->errstr );
            break;
        }

        if(pwd != NULL && strcmp(pwd, "") != 0)
        {
            LOG_DEBUG("RedisDBMgr::auth password=%s", pwd);
            redisReply* reply = (redisReply*)redisCommand(connect, "auth %s", pwd);
            if (reply->type != REDIS_REPLY_STATUS || reply->str == NULL)
            {
                LOG_DEBUG("RedisDBMgr::Connect fail type=%d", reply->type);
                freeReplyObject(reply);
                break;
            }

            if(strcasecmp(reply->str, "OK"))
            {
                LOG_DEBUG("RedisDBMgr::Connect fail %s", reply->str);
                freeReplyObject(reply);
                break;
            }

            freeReplyObject(reply);
        }

        LOG_DEBUG("RedisDBMgr::Connect SUCC");
        return 0;
    }while(void(0), 0);

    if(connect != NULL)
    {
        redisFree(connect);
        connect = NULL;
    }
    LOG_DEBUG("RedisDBMgr::Connect fail");
    return -1;
}

int RedisDBMgr::Get(const std::string& key, unsigned int& value)
{  
    redisReply* reply = (redisReply*)redisCommand(master_connect_, "get %s", key.c_str());
    if (reply == NULL)
    {
        freeReplyObject(reply);
        LOG_ALERT("RedisDBMgr::Get REPLY NULL");
        return E_AUTH_REDIS_GET_FAIL_REPLY_NULL;   //写回user_id失败了
    }

    if (reply->type == REDIS_REPLY_ERROR)
    {
        freeReplyObject(reply);
        LOG_ALERT("RedisDBMgr::Get REPLY ERROR errmsg=%s", reply->str);
        return E_AUTH_REDIS_GET_FAIL_ERROR;   //写回user_id失败了
    }
    else  if (reply->type == REDIS_REPLY_INTEGER)
    {
        value = (unsigned int)reply->integer;
    }
    else if (reply->type == REDIS_REPLY_STRING)
    {
        value = (unsigned int)atoi(reply->str);
    }

    freeReplyObject(reply);
    return 0;
}

int RedisDBMgr::Set(const std::string& key, unsigned int value)
{
    redisReply* reply = (redisReply*)redisCommand(master_connect_, "set %s %d", key.c_str(), value);
    if (reply == NULL)
    {
        freeReplyObject(reply);
        LOG_ALERT("RedisDBMgr::Set REPLY NULL");
        return E_AUTH_REDIS_SET_FAIL_REPLY_NULL;   //写回user_id失败了
    }

    if (reply->type == REDIS_REPLY_ERROR)
    {
        freeReplyObject(reply);
        LOG_ALERT("RedisDBMgr::Set REPLY ERROR errmsg=%s", reply->str);
        return E_AUTH_REDIS_SET_FAIL_ERROR;   //写回user_id失败了
    }

    freeReplyObject(reply); 
    return 0;
}

int RedisDBMgr::Incr(const std::string& key, unsigned int& user_id)
{
    redisReply* reply = (redisReply*)redisCommand(master_connect_, "INCR %s ", key.c_str());
    if (reply->type == REDIS_REPLY_INTEGER)
    {
        user_id = (unsigned int)reply->integer;
        freeReplyObject(reply);
        return 0;
    }
    else
    {
        user_id = 0;
        freeReplyObject(reply);
        return E_AUTH_REDIS_INCR_FAIL;
    }
}

int RedisDBMgr::CreateUserID(unsigned int& user_id)
{
    return Incr(REDIS_USEDID_KEY, user_id);   
}

c++链接redis很简单,只要熟悉封装好的api就能顺利的进行redis的开发.上面的代码展示了一些常用api的用法,这里就不对其他的api做详细介绍了。

本文地址：https://www.stayed.cn/item/123

转载请注明出处。

本站部分内容来源于网络,如侵犯到您的权益,请 联系我