Redis报错：
StackExchange.Redis.RedisServerException: Endpoint 127.0.0.1:7200 serving hashslot 12448 is not reachable at this point of time.
间接引发错误：
1：Timeout performing LPOP WebSrvc_LocalLog, inst: 3, mgr: CheckForStaleConnections, err: never, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: SER-070-196, serverEndpoint: 192.168.70.101:6379, keyHashSlot: 9618, IOCP: (Busy=0,Free=1000,Min=16,Max=1000), WORKER: (Busy=0,Free=8191,Min=16,Max=8191) (Please take a look at this article for some common client-side issues that can cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts)
2：SocketFailure on LPOP
2：SocketFailure on LPOP
原因：
1.Redis 集群间配置不一致，造成 hashslot 主子节点之间一直在交互,具体和写AOF快照有关，可能是Redis 的一个Bug。
2.StackExchange.Redis 的 链接 字符串 错误：必须 链接 master（如果Redis是集群的话），链接的slave 也会报这个错误。
解决方式：
1：可以重新配置 集群。
2：
config set no-appendfsync-on-rewrite no （注：在本人遇到的问题中，发现其中一个节点的 主子节点的 no-appendfsync-on-rewrite 设置成了 yes，redis 建议设置成no，设置成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 as
# "no" that is the safest pick from the point of view of durability.
# 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 as
# "no" that is the safest pick from the point of view of durability.
＃当AOF fsync策略设置为always或者每秒，以及背景时
＃保存过程（后台保存或AOF日志背景重写）是
＃在一些Linux配置中，对磁盘执行大量的I / O操作
＃Redis可能在fsync（）调用上阻塞太久。请注意，没有修复
＃目前，即使在不同的线程执行fsync将阻止
＃我们的同步写（2）调用。
＃
＃为了减轻这个问题，可以使用下面的选项
＃将阻止在主进程中调用fsync（），而a
＃BGSAVE或BGREWRITEAOF正在进行中。
＃
＃这意味着，当另一个孩子正在储蓄时，Redis的耐用性是
＃与“appendfsync none”相同。实际上，这意味着它是
＃可能会丢失高达30秒的最糟糕的情况下登录（与
＃默认的Linux设置）。
＃
＃如果您有延迟问题，请将其转为“是”。否则，将其保留为
＃“不”从持久性的角度来看是最安全的选择。
＃保存过程（后台保存或AOF日志背景重写）是
＃在一些Linux配置中，对磁盘执行大量的I / O操作
＃Redis可能在fsync（）调用上阻塞太久。请注意，没有修复
＃目前，即使在不同的线程执行fsync将阻止
＃我们的同步写（2）调用。
＃
＃为了减轻这个问题，可以使用下面的选项
＃将阻止在主进程中调用fsync（），而a
＃BGSAVE或BGREWRITEAOF正在进行中。
＃
＃这意味着，当另一个孩子正在储蓄时，Redis的耐用性是
＃与“appendfsync none”相同。实际上，这意味着它是
＃可能会丢失高达30秒的最糟糕的情况下登录（与
＃默认的Linux设置）。
＃
＃如果您有延迟问题，请将其转为“是”。否则，将其保留为
＃“不”从持久性的角度来看是最安全的选择。