为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】 场景 + 问题概述
【应用框架及开发适配业务逻辑】
【背景】 做过哪些操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【TiDB 版本】
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
在election time这段时间内，即使 region Leader本身故障（比如发生了网络分区）也仍然作为region Leader，这时数据读取的方式是Lease read，即local read，
那么这时数据写入这个region Leader还会成功吗？还如何与其它节点region协同？
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
不会成功，因为log replication不会获得大多数节点的响应
这是raft协议保证的
保证奇数节点数就行了，如果是偶数节点，可能会出现副本不全的情况，导致集群无法正常工作
raft协议
raft 协议 多数派表决，会处理网络分区的问题
多副本，还有投票机制，leader会投票的
写入的话，需要大多数节点接受日志，才能返回写入成功
也需要关注pd和哪些tikv在一个网络分区。
主要是raft保证的
raft选主
可以先了解下 raft协议
TiKV处理脑裂的情况主要依赖于Raft协议。在election time这段时间内，即使region Leader本身故障（比如发生了网络分区）也仍然作为region Leader，这时数据读取的方式是Lease read，即local read。这种方式可以保证线性一致性，即在某个时间点我们写入了一个值，那么在这个时间点之后，我们的读一定能读到这个值，不可能读到这个时间点之前的值[*]。
另外，如果发生脑裂，客户端请求到了少数集群，不会收到Ack，再次尝试请求，此时请求了多数集群，会收到Ack。当网络恢复后，少数集群会自动成为 Follower[*]。
如果大于半数的pd节点损坏，我们可以直接参照节点全部损坏的场景去做，或者按照脑裂的方式都是可以的，因为大于半数节点损坏之后集群就无法选出leader了，或者也可以按照脑裂的样例单独启动一个节点再对其他的节点进行缩容扩容处理[*]。
raft协议可以保证
raft协议
学习了，感谢分享
不会成功，因为log replication不会获得大多数节点的响应
raft