Raft 是个强 Leader 模型，只由 Leader 处理客户端请求，就算客户端连接了 Follower，Follower 也会把请求转发给 Leader 处理。

Raft 论文 5.1 节：

The leader handles all client requests (if a client contacts a follower, the follower redirects it to theleader).

第 3 个问题：D、E 不会成为 Leader，因为它们的日志比 B、C 的日志更旧，B 和 C 不会投票给 D 和 E。看最后一句：

会,但是实际上基于 raft 的 etcd 实现了 Linearizable Read 来解决这个问题

读请求到了 follower 后,follower会去向 leader 请求 readindex(也就是当时 leader 的 commitindex), leader 在确认自己还是 leader 之后,就会吧 readindex 发给 follower,follower 会对比自己的 commitindex 和 readindex,只有commitindex 大于等于 readindex 之后,才能读取数据返回.

假设有A, B, C, D, E 5个节点(当前状态都是x), 客户端发送一个状态更新请求 x->y, 写入了A, B, C三个节点, 然后被确认保存了(A, B, C都committed).

1. 如果在D, E还未同步到y的时候(D, E中没有uncommited的状态), 客户端去D拿状态了, 此刻D的状态还是x, 这时候怎么保证一致性?
2. 如果D中的y状态尚处于uncommitted, 客户端去D拿状态了, 此时又是怎么处理?

加两个问题:
3 . A是Leader, 5个节点的数据是: A(0), B(0), C(0), D(0), E(0);
写入3并确认, 节点: A(0, 3), B(0, 3), C(0, 3), D(0), E(0);
如果此时A挂了, 在B, C, D, E中重新选举, 那么D, E会成为新Leader吗? 如果E成为了Leader, E的数据并不全, 怎么办?

4 . A是Leader, 5个节点的数据是: A(0), B(0), C(0), D(0), E(0);
写入3并确认, 节点: A(0, 3), B(0, 3), C(0, 3), D(0, 3-uncommitted), E(0, 3-uncommitted);
如果此时A挂了, 那么D, E会成为新Leader吗? 如果E成为了Leader, E还有一条uncommitted的数据怎么处理?

当然要一样
接口就是一种基本的方法集、数据类型集，不涉及到具体的实现，可以看成是一种预定义。
而你的类型struct，类似我们说的对象，类型（对象）要实现接口，那么必须实现接口里边的方法，与接口里边的方法一致（包括方法的返回值类型一致）我们才能说实现了那个接口。

ProductA---》实现了 接口Product
其中CreatorA想要实现Creator接口，就得实现Creator接口里边的Produce方法；
这个方法必须返回Product接口；
换句话说，想要CreatorA实现Creator接口，在实现这个接口里边的Produce方法的时候，要保持与接口里边这个方法一致，返回值一致,也就是返回Prokuct接口才行

而你定义的这个Produce方法，返回的是ProductA（一个实现了Product接口的对象），不是Product接口，返回值类型不一样(虽然它底层实现了Product接口)，也不能说实现了
必须是func(c *CreatorA) Produce() Product

由此可见，golang中接口与方法实现，要求还挺严格的，实现的接口方法返回值必须一致才行,光底层一致不行

golang 强调组合，面向接口编程。
可以模拟面向对象效果(同js用原型实现一样），
但从本质上非支持像java，php这种原生对象继承特性,
即子类型也是父类，扩展后的接口集类型亦是未扩展之前的接口类型，这些不需要显式转换。
它们自动支持子类型（向上转型），扩展行为接口类型也是未扩展（接口）行为集类型。
换而言之，go 大多数情况下，不承认接口子类型（因其压根就没有父子继承关系），不会隐式自动转换，规定是什么类型就是什么类型不打折扣，哪怕底类型一样，如下所示

func(){
   type int2 int
   a := 7
   fmt.Println(reflect.TypeOf(a))
   var b int2 = 7
   fmt.Println(reflect.TypeOf(b),a == b)  // 是否相等？
}

比如现在有产品接口(Product)和具体的产品A(ProductA):

// Product 产品接口
type Product interface {
    GetInfo() string
}

// ProductA 具体产品A, 实现了Product接口
type ProductA struct {
    name string
}

func (p *ProductA) GetInfo() string {
    return p.name
}

生产者接口(Creator)和具体生产者A(CreatorA):

// Creator 生产者接口
type Creator interface {
    Produce() Product   // 接口方法声明返回值是一个产品接口类型
 }
 
 // CreatorA 具体生产者A
 type CreatorA struct {}
 
 func (c *CreatorA) Produce() *ProductA {   // 这样写CreatorA就没实现接口Creator
    return &ProductA{"xxx"}
}

*ProductA是一个实现了接口Product的类型, 但是func(c *CreatorA) Product() *ProductA却不符合接口Creator?
只有写成func(c *CreatorA) Product() Product才符合了接口Creator, 那是不是就是说具体方法的声明要跟接口声明写的一毛一样才有效?

解决了, 自答一下.
先说怎么解决的. 刚才一直在疯狂查办法, 各种尝试, 最终成功的是在add_header Access-Control-Allow-Origin * always这个设置后面加"always", 加完发现好使了!

再说下根本原因, 其实问题不在缺了"always"这个配置上, 这个配置并不是必须的, 关键在于add_header命令对响应码是有要求的!!!!

而我写上面的login接口时很放飞自我的返回了个202 -_-! 正好不在允许范围

前端是vue-element-admin的后台系统, 后端接口用flask写的, vue和flask都通过nginx部署的, nginx里加了对跨域的处理, 但是前端的GET请求正常, post请求就不行了.

这是后端的nginx部署:

这是vue的nginx部署:

下面是OPTIONS和POST请求:


有这样的报错提示:

在没有给nginx加那三个处理跨域的头部前, GET请求也是会报错的, 加上之后GET请求成功了, 那我感觉跨域应该是起作用了的, 但是POST的这个实在不知道问题在哪里

你这种理解感觉有点问题。

Celery的任务触发和执行是分开的。怎么会出现前多少个任务，后多少个任务呢。

每天的12:00有100个任务要执行你这意思是定义了100个crontab? 时间到了就会触发任务，扔到队列，至于执行 那是worker的事了。

使用celery beat的crontab模式进行任务调度, 假设在每天的12:00有100个任务要执行, 每个任务都有一定的耗时, 如果在执行完50个任务后到了12:01, 剩下的50个任务还会继续执行吗?