详解Redis的AOF持久化方式以及aof日志重写配置以及对redis中的GEO地理位置数据类型命令的应用示例

一、详解Redis的AOF持久化方式以及aof日志重写配置

    研究Redis并不是一个很复杂而且要去钻研其它很多东西的事情，在熟悉redis的命令的同时，最重要的是要去看Redis的配置文件，因为REDIS中的配置文件真的写得太详细了。我进行了一下统计，整个配置文件中总共也就50来行是实际配置值（当然有一些行是备用配置选项），而整个配置文件行数达到1000+行（当然有空行或者只有#字符的行，当然这也是形成一个配置文件逻辑条理性的应用的行）。算下来注释代码(和空行)占据了95%。可见REDIS配置文件写得真的很用心。如下统计:

[root@007 conf]# grep -vE "^$|^#" 6379.conf  | wc -l
53
[root@007 conf]# wc -l 6379.conf            
1023 6379.conf

    AOF( append only file )是独立的持久化日志方式来记录REDIS的写命令，并在 Redis 重启时在重新执行 AOF 文件中的命令以达到恢复数据的目的，AOF 的主要作用是解决数据持久化的实时性。简单理解就是怕写在REDIS中的数据丢失，对写进REDIS的数据进行立即或者按时间规律写入到磁盘永久存储。接下来我就们就来详细认真地看一下配置文件中关于AOF的配置以及注释吧。

1. 第一项配置：appendonly

appendonly功能的开关以及记录的文件地址

appendonly no
appendfilename "appendonly.aof"
    By default Redis asynchronously dumps the dataset on disk. This mode is good enough in many applications, but an issue with the Redis process or a power outage may result into a few minutes of writes lost (depending on the configured save points).The Append Only File is an alternative persistence mode that provides much better durability. For instance using the default data fsync policy (see later in the config file) Redis can lose just one second of writes in a dramatic event like a server power outage, or a single write if something wrong with the Redis process itself happens, but the operating system is still running correctly. AOF and RDB persistence can be enabled at the same time without problems. If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.

    默认情况下，Redis异步将数据集转储到磁盘上。此模式在许多应用程序中已经足够好，但是Redis进程问题或断电可能会导致几分钟的写入丢失（取决于配置的保存点）。“仅附加文件”是一种替代性的持久性模式，可提供很多功能更好的耐久性。例如，使用默认数据fsync策略（请参阅配置文件中的稍后内容），Redis可能在服务器断电等严重事件中丢失一秒钟的写入，如果Redis进程本身发生错误，则一次写入将丢失一次，但是操作系统仍在正常运行。可以同时启用AOF和RDB持久性，而不会出现问题。如果在启动时启用了AOF，则Redis将加载AOF，即该文件具有更好的持久性保证。

3. 第二项配置：appendfsync 告。

        appendfsync 告诉操作系统是数据实时写入磁盘always，还是每秒操作一次sync写入磁盘everysec，还是设置为no让操作系统自动处理no

appendfsync everysec #默认配置

    # The fsync() call tells the Operating System to actually write data on disk instead of waiting for more data in the output buffer. Some OS will really flush data on disk, some other OS will just try to do it ASAP. Redis supports three different modes:
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
The default is "everysec", as that's usually the right compromise between speed and data safety. It's up to you to understand if you can relax this to "no" that will let the operating system flush the output buffer when it wants, for better performances (but if you can live with the idea of some data loss consider the default persistence mode that's snapshotting), or on the contrary, use "always" that's very slow but a bit safer than everysec.

    ＃fsync（）调用告诉操作系统将数据实际写入磁盘，而不是等待输出缓冲区中的更多数据。有些操作系统确实会刷新磁盘上的数据，而另一些操作系统只会尝试尽快完成该操作。 Redis支持三种不同的模式：
＃否：不要fsync，只要让OS在需要时刷新数据即可。快点。
＃always：每次写入仅附加日志后，fsync。慢，最安全。
＃everysec：每秒仅同步一次fsync。妥协。
默认值为“ everysec”，因为这通常是速度和数据安全性之间的正确折衷。您可以了解是否可以将其放宽为“ no”，以便操作系统在需要时刷新输出缓冲区，以获得更好的性能（但是如果您可以忍受某些数据丢失的想法，请考虑使用默认的持久模式（即快照），或者相反，请使用“总是”，该速度非常慢，但比securesec更安全。

3. 第三项配置：no-appendfsync-on-rewrite

        no-appendfsync-on-rewrite 当REDIS在操作BGSAVE或BGREWRITEAOF这种大量sync的动作时，第二项配置的appendfsync是不是置为no。即让步于REDIS的BGSAVE或BGREWRITEAOF这种操作。

no-appendfsync-on-rewrite no #默认配置

    #When the AOF fsync policy is set to always or everysec, and a background saving process (a background save or AOF log background rewriting) is performing a lot of I/O against the disk, in some Linux configurations Redis may block too long on the fsync() call. Note that there is no fix for this currently, as even performing fsync in a different thread will block our synchronous write(2) call. In order to mitigate this problem it's possible to use the following option that will prevent fsync() from being called in the main process while a BGSAVE or BGREWRITEAOF is in progress. This means that while another child is saving, the durability of Redis is the same as "appendfsync none". In practical terms, this means that it is possible to lose up to 30 seconds of log in the worst scenario (with the default Linux settings).If you have latency problems turn this to "yes". Otherwise leave it a "no" that is the safest pick from the point of view of durability.

    #当AOF fsync策略设置为always或everysec，并且后台保存进程（后台保存或AOF日志后台重写）对磁盘执行大量I / O时，在某些Linux配置中，Redis可能会在磁盘上阻塞太长时间。 fsync（）调用。请注意，目前尚无此修复程序，因为即使在其他线程中执行fsync也将阻止我们的同步write（2）调用。为了缓解此问题，可以使用以下选项来防止在BGSAVE或BGREWRITEAOF进行时在主进程中调用fsync（）。这意味着当另一个进程正在保存时，Redis的持久性与“ appendfsync none”相同。实际上，这意味着在最坏的情况下（使用默认的Linux设置），最多可能会丢失30秒的日志。如果存在延迟问题，请将其设置为“是”。否则，从耐用性的角度来看，这是最安全的选择。

4. 第四项配置：auto-aof-rewrite

        auto-aof-rewrite相关配置。为防止AOF文件过大，redis会重写aof文件，这里设置的就是触发AOF重写的百分比和大小阈值。百分比置为0即禁止重写。

auto-aof-rewrite-percentage 100    #自动改写百分比100
auto-aof-rewrite-min-size 64mb     #自动改写最小大小64mb

    # Automatic rewrite of the append only file. Redis is able to automatically rewrite the log file implicitly calling BGREWRITEAOF when the AOF log size grows by the specified percentage. This is how it works: Redis remembers the size of the AOF file after the latest rewrite (if no rewrite has happened since the restart, the size of the AOF at startup is used). This base size is compared to the current size. If the current size is bigger than the specified percentage, the rewrite is triggered. Also you need to specify a minimal size for the AOF file to be rewritten, this is useful to avoid rewriting the AOF file even if the percentage increase is reached but it is still pretty small. Specify a percentage of zero in order to disable the automatic AOF rewrite feature.

    ＃自动重写仅附加文件。 当AOF日志大小增加指定百分比时，Redis可以自动重写日志文件，隐式调用BGREWRITEAOF。 它是这样工作的：Redis会在最近一次重写后记住AOF文件的大小（如果自重新启动以来未发生任何重写，则使用启动时AOF的大小）。 将此基本大小与当前大小进行比较。 如果当前大小大于指定的百分比，则触发重写。 另外，您需要指定要重写的AOF文件的最小大小，这对于避免重写AOF文件非常有用，即使达到百分比增加，但它仍然很小。 指定零百分比以禁用自动AOF重写功能。

5. 第五项配置：aof-load-truncated

        aof-load-truncated 启用aof之后，redis重启默认会使用aof文件加载数据，此配置即是允许redis自行对aof文件进行截断(可能最后一行有问题)以保证redis正常启动。

aof-load-truncated yes #默认配置

    # An AOF file may be found to be truncated at the end during the Redis startup process, when the AOF data gets loaded back into memory. This may happen when the system where Redis is running crashes, especially when an ext4 filesystem is mounted without the data=ordered option (however this can't happen when Redis itself crashes or aborts but the operating system still works correctly). Redis can either exit with an error when this happens, or load as much data as possible (the default now) and start if the AOF file is found to be truncated at the end. The following option controls this behavior. If aof-load-truncated is set to yes, a truncated AOF file is loaded and the Redis server starts emitting a log to inform the user of the event. Otherwise if the option is set to no, the server aborts with an error and refuses to start. When the option is set to no, the user requires to fix the AOF file using the "redis-check-aof" utility before to restart the server. Note that if the AOF file will be found to be corrupted in the middle the server will still exit with an error. This option only applies when Redis will try to read more data from the AOF file but not enough bytes will be found.

    ＃当AOF数据重新加载到内存中时，在Redis启动过程中可能会发现AOF文件在末尾被截断。当运行Redis的系统崩溃时，尤其是在没有data = ordered选项的情况下挂载ext4文件系统时，可能会发生这种情况（但是，当Redis本身崩溃或中止，但操作系统仍然可以正常运行时，就不会发生这种情况）。Redis可以在发生这种情况时退出并显示错误，也可以加载尽可能多的数据（当前为默认值），如果发现AOF文件最后被截断，则可以开始。以下选项控制此行为。如果aof-load-truncated设置为yes，则将加载截短的AOF文件，并且Redis服务器将开始发出日志以将事件通知用户。否则，如果该选项设置为no，则服务器将中止并显示错误，并拒绝启动。如果将该选项设置为no，则用户需要在重新启动服务器之前使用“ redis-check-aof”实用程序修复AOF文件。请注意，如果在中间发现AOF文件已损坏，则服务器仍将退出并出现错误。仅当Redis尝试从AOF文件读取更多数据但找不到足够的字节时，此选项才适用。

二、对redis中的GEO地理位置数据类型命令的应用示例

    本文主要是对REDIS中的GEO数据类型命令进行应用了解，GEO对这种LBS基于位置距离计算的应用有了一个很大的支持，在没有这种东西之前可能将这种计算写入MYSQL的存储过程，然后在查询的时候直接使用存储函数进行计算按距离进行排序，而现在可以将这些数据放在REDIS中，查询处理将会比MYSQL更快，同时会更灵活。

    GEO的可用命令列表在这里有一个了解：Redis 中GEO地理位置的功能函数及 Redis 分布式锁的应用_redis geometry函数-CSDN博客这里就开始对GEO位置函数进行应用。整个过程就是我们往REDIS中添加几个城市的位置，包括北京天津以及北京3、4、5环上各选了一个位置的经纬度数据。取经纬度数据也有一个很方便的工具，地址：拾取坐标系统 。具体的命令过程见下面的命令执行过程以及备注：

#1.使用geoadd命令往redis中添加一个位置北京的天安门位置和天津位置的经纬度
127.0.0.1:6379> geoadd citys 116.405419 39.916927 beijing
(integer) 1
127.0.0.1:6379> geoadd citys 117.227548 38.996584 tianjin
(integer) 1
#2.使用GEOPOS取得citys这个KEY中的成员beijing数据
#可以发现返回的经纬度数据与我们输入的不完全一样，这个应该和计算机的float表示有关，不影响
127.0.0.1:6379> geopos citys beijing
1) 1) "116.40541702508926392"
   2) "39.91692695957298298"
127.0.0.1:6379> geopos citys tianjin
1) 1) "117.22754627466201782"
   2) "38.99658491494397339"
#获取不存在的number成员直接返回nil
127.0.0.1:6379> geopos citys shanghai
1) (nil)
#3.使用GEODIST命令计算两个number成员之间的距离，如下得到默认单位124351.4471米
127.0.0.1:6379> geodist citys beijing tianjin
"124351.4471"
#可以指定单位，比如km以及英里等，得到124.3514km
127.0.0.1:6379> geodist citys beijing tianjin km
"124.3514"
#接下来添加北京三环、四环、五环上各一个位置点。
127.0.0.1:6379> geoadd citys 116.400388 39.863559 beijing3
(integer) 1
127.0.0.1:6379> geoadd citys 116.281381 39.927994 beijing4
(integer) 1
127.0.0.1:6379> geoadd citys 116.550154 39.921797 beijing5
(integer) 1
#4.使用GEORADIUS命令获取citys下离各成员离 116.402113 39.92224位置的距离，可以使用WITHDIST返回距离值以及指定单位，如下：
127.0.0.1:6379> georadius citys 116.402113 39.92224 200 km WITHDIST
1) 1) "beijing4"
   2) "10.3180"
2) 1) "beijing"
   2) "0.6547"
3) 1) "beijing5"
   2) "12.6283"
4) 1) "beijing3"
   2) "6.5286"
5) 1) "tianjin"
   2) "124.9975"
#可以使用 WITHCOORD，将位置元素的经度和维度也一并返回
127.0.0.1:6379> georadius citys 116.402113 39.92224 200 km WITHDIST WITHCOORD
1) 1) "beijing4"
   2) "10.3180"
   3) 1) "116.28138095140457153"
      2) "39.92799355215466051"
2) 1) "beijing"
   2) "0.6547"
   3) 1) "116.40541702508926392"
      2) "39.91692695957298298"
3) 1) "beijing5"
   2) "12.6283"
   3) 1) "116.55015438795089722"
      2) "39.92179615892008115"
4) 1) "beijing3"
   2) "6.5286"
   3) 1) "116.40039056539535522"
      2) "39.86355840556310426"
5) 1) "tianjin"
   2) "124.9975"
   3) 1) "117.22754627466201782"
      2) "38.99658491494397339"
#可以使用ASC/DESC进行按远近排序，这个就很有用 了。另外可以指定距离在200KM以内的位置点
127.0.0.1:6379> georadius citys 116.402113 39.92224 200 km WITHDIST ASC
1) 1) "beijing"
   2) "0.6547"
2) 1) "beijing3"
   2) "6.5286"
3) 1) "beijing4"
   2) "10.3180"
4) 1) "beijing5"
   2) "12.6283"
5) 1) "tianjin"
   2) "124.9975"
#5.GEORADIUSBYMEMBER命令不用传具体经纬度进去，而是选定已经存在的一个成员如beijing，要求100KM,天津 就没有出现了。
127.0.0.1:6379> GEORADIUSBYMEMBER citys beijing 100 km WITHDIST ASC
1) 1) "beijing"
   2) "0.0000"
2) 1) "beijing3"
   2) "5.9515"
3) 1) "beijing4"
   2) "10.6518"
4) 1) "beijing5"
   2) "12.3587"
 #6.最后可以使用geohash，返回经纬度的唯一表示值，这个目前未发现用处，估计主要进行位置的一致性比对。
127.0.0.1:6379> geohash citys beijing
1) "wx4g0feufy0"