# raft group 超时选举

![center](./student-guide/diagram/place-holder.png)
------------------------------------------------------------
raft group 超时选举
每一个 RaftGroup 中的 Leader 通过 Raft 状态机将心跳信息发送给其他 Region 副本，来达到维持 Leader 地位的目标，Raft 状态机则由 Raftstore 来驱动。
所以，在介绍 Leader drop 相关问题前，我们一起来简单了解下 Raftstore 的工作流程。一个 TiKV 实例上有多个 Region。Region 消息是通过 Raftstore 模块驱动 Raft 状态机来处理的。这些消息包括 Region 上读写请求的处理、Raft log 的持久化和复制、Raft 的心跳处理等。以下是 TiKV 的模块 Raftstore 的工作流程示意图：

如图所示，从 TiDB 发来的请求会通过 gRPC 和 storage 模块变成最终的 KV 读写消息，并被发往相应的 Region，而这些消息并不会被立即处理而是被暂存下来。Raftstore 会轮询检查每个 Region 是否有需要处理的消息。如果 Region 有需要处理的消息，那么 Raftstore 会驱动 Raft 状态机去处理这些消息，并根据这些消息所产生的状态变更去进行后续操作。例如，在有写请求时，Raft 状态机需要将日志落盘并且将日志发送给其他 Region 副本；在达到心跳间隔时，Raft 状态机需要将心跳信息发送给其他 Region 副本。
我们可以看到，Raftstore 主要承担两种消息类型，写请求产生的消息，以及 Region 间的心跳消息。目前并没有在 Raftstore 设计单独的线程来处理 Region 心跳消息，这些消息通过 gRPC 发生给其他的 TiKV 节点中的 Region 副本。其中写请求产生的消息会在本地落盘后，再发送给其他 Region 副本。从这个过程中，我们可以看到，一个 Region 的心跳信息能够正常发出高度依赖：写入性能以及网络环境两大要素。
当网络环境，写入性能出现问题，或 TiKV 异常重启，Raft 状态机无法及时发出心跳信息，并且在达到 Raft 超时时间后，重新发起 Leader 选举。