本发明涉及容错处理方法，具体涉及一种数据写入redis失败的快速容错处理方法。
背景技术：
redis是现在使用最普遍的缓存数据存储系统，和memcached等缓存存储系统相比，redis不仅支持发布/订阅、主从等部署方式；还支持更多的数据类型，而每种数据类型都提供了丰富的操作指令。redis中间件为其他业务系统提供统一接口访问服务。主从与哨兵化的集成服务管理可以增加灾难下的服务器容错，但因为服务的提供是通过网络进行，所以在使用过程中可能因为网络信号或redis自身的原因导致通信不能正确建立，此时，正在执行的业务数据将会丢失。
技术实现要素：
本发明的目的在于提供一种数据写入redis失败的快速容错处理方法，解决在redis服务使用过程中可能因为网络信号或redis自身的原因导致通信不能正确建立，正在执行的业务数据将会丢失的问题。
为解决上述的技术问题，本发明采用以下技术方案：
一种数据写入redis失败的快速容错处理方法，包括下列步骤：
s1：将执行失败的redis业务作为容错任务添加到容错待处理队列中；
s2：从容错待处理队列中获取容错待处理任务并判断是否存在容错待处理任务，若存在容错待处理任务，则重新执行redis业务，并且该redis业务重复执行的次数加1，继续执行s3步骤；若不存在容错待处理任务，执行s4步骤；
s3：判断s2步骤中重新执行redis任务是否成功，若执行成功，则保存到redis服务器集群，跳到s2继续执行；若执行失败，则将该redis业务再次添加到容错待处理队列中，并跳到s2步骤继续执行；
s4：关闭redis服务。
更进一步的方案是，容错任务按照顺序加入容错待处理队列的末端，容错任务的处理顺序为先处理容错待处理队列首端的容错任务。容错处理需严格按照业务执行顺序进行处理，所以容错任务要按顺序依次加入容错待处理队列的尾端，任务的处理顺序为先处理队首任务。
更进一步的方案是，s3步骤中，若重新执行redis业务失败将该redis业务再次添加到容错待处理队列中应添加到容错待处理队列的首端。容错任务在处理过程中，可能继续出错或失败，在重新加入容错待处理队列时，为了保证业务的顺序执行，需要将容错任务放入容错待处理队列的首端，这样才能够在队列先处理队首任务的情况下，保证业务顺序执行，避免业务颠倒而出错。
更进一步的方案是，容错待处理队列为自定义的同步链表。容错待处理队列为自定义的同步链表，能够确保加入及处理的容错任务有序。
更进一步的方案是，容错待处理队列采用数据库实现。容错待处理队列可扩展为数据库实现，从而保证容错任务全局统一化处理。
更进一步的方案是，对上述容错任务配置最大重复执行的次数，若重复执行的次数已超过所配置的最大重复执行的次数，则将该redis业务保存到数据库中作持久化处理。在容错处理的过程中，由于网络连接或redis服务中断的原因，redis业务重新执行可能一直执行失败，为了保证业务的流畅性，可以将redis业务保存到数据库中作持久化处理，待网络恢复，用户根据需要再重新执行，因此可配置待处理容错任务的继续重试次数，超过次数时，写入mysql做持久化处理。（如写入失败，需记录详细日志）。
更进一步的方案是，将redis业务保存到数据库后根据用户实际需要确定redis重新执行的时间。
与现有技术相比，本发明的有益效果是：
本发明通过对需要使用redis来进行业务处理的方法提供了一致的框架支持，使用方便简单。
本发明针对处理失败的任务将进行不间断重试，直到任务执行成功。有效解决了因网络连接或redis服务中断所引起的数据丢失问题，保证了业务执行的流畅性。
附图说明
图1为本发明的流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
实施例1：
一种数据写入redis失败的快速容错处理方法，如图1所示，包括：业务开始，执行redis业务，判断redis业务是否执行成功，若执行成功，则保存到redis服务器集群，若redis业务执行失败，则执行下列步骤：
s1：将执行失败的redis业务作为容错任务添加到容错待处理队列中；
s2：从容错待处理队列中获取容错待处理任务并判断是否存在容错待处理任务，若存在容错待处理任务，则重新执行redis业务，并且该redis业务重复执行的次数加1（其中该redis业务重复执行的次数的初始值为0），继续执行s3步骤；若不存在容错待处理任务，执行s4步骤；
s3：判断s2步骤中重新执行redis任务是否成功，若执行成功，则保存到redis服务器集群，跳到s2继续执行；若执行失败，则将该redis业务再次添加到容错待处理队列中，并跳到s2步骤继续执行；
s4：关闭redis服务。
其中，容错任务按照顺序加入容错待处理队列的末端，容错任务的处理顺序为先处理容错待处理队列首端的容错任务。容错处理需严格按照业务执行顺序进行处理，所以容错任务要按顺序依次加入容错待处理队列的尾端，任务的处理顺序为先处理队首任务。
s3步骤中，若重新执行redis业务失败将该redis业务再次添加到容错待处理队列中应添加到容错待处理队列的首端。容错任务在处理过程中，可能继续出错或失败，在重新加入容错待处理队列时，为了保证业务的顺序执行，需要将容错任务放入容错待处理队列的首端，这样才能够在队列先处理队首任务的情况下，保证业务顺序执行，避免业务颠倒而出错。
本实施例中将执行失败的redis业务作为容错任务添加到容错待处理队列中，将容错待处理队列中的容错任务顺序执行，并针对处理失败的任务将进行不间断重试，直到任务执行成功。有效解决了因网络连接或redis服务中断所引起的数据丢失问题，保证了业务执行的流畅性。
实施例2：
为了确保加入及处理的容错任务有序，在实施例1的基础上，容错待处理队列为自定义的同步链表。
实施例3：
为了保证容错任务全局统一化处理，在实施例1或实施例2的基础上，容错待处理队列采用数据库实现。
实施例4：
在实施例3的基础上，对上述容错任务配置最大重复执行的次数，若重复执行的次数已超过所配置的最大重复执行的次数，则将该redis业务保存到数据库中作持久化处理。将redis业务保存到数据库后根据用户实际需要确定redis重新执行的时间。
本实施例在容错处理的过程中，由于网络连接或redis服务中断的原因，redis业务重新执行可能一直执行失败，为了保证业务的流畅性，可以将redis业务保存到数据库中作持久化处理，待网络恢复，用户根据需要再重新执行，因此可配置待处理容错任务的继续重试次数，超过次数时，写入mysql做持久化处理。（如写入失败，需记录详细日志）。
尽管这里参照本发明的多个解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开、附图和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变形和改进外，对于本领域技术人员来说，其他的用途也将是明显的。