## 临时笔记 人无法同时把精力集中在多个地方，所以我现在应该集中精力放在后端，然后再来前端，各个击破才是王道，不然徘徊不前，左右不是，这种处境很糟糕。 * * * * * 第一步实现系统，第二部就要开始做性能优化了，比如加索引 * * * * * 方案报价 价格 方案执行 价格（白总可以修改的价格） 新客户：没有做过广告 || 没拜访记录 “新/老”不是针对于个人，而是客户属性 白总分配行业给副总，副总就得到行业下的客户，副总一下，包括副总都可以看到这些客户。 * * * * * // 定时任务一分钟执行一次。 // 执行时打一个点，上次的点如果不存在，则以90天前为点 // 再次执行时，获取当前时间，到上一个点内的更新订单，并再次打点 // 在分页过程取的过程中，要发出多次请求，多次请求的参数时间区间是一样的，也就是区间固定了，只是每次页码不同，首先明确这点很重要 // 此接口返回订单列表的排序时按照最后更新时间倒序排序的 // 上面说过，订单散落在时间线上，是有排序规则，并且更新时会向前移动的 // 这个很重要，这里面的细节是关键，包含了依据此接口同步订单的基本原理 // 先来想一个问题，可能容易忽略的问题，订单为什么会发生更新呢？它自己更新吗？什么时候更新呢？ // 这是这个问题的关键，理解这个问题了，你就彻底理解这种根据最后时间（区间）增量查询订单的精髓了。 // 订单之所以会更新是因为状态发生变化了，它自己肯定不能自动更新，肯定是操作使它状态发生改变，比如用户支付，系统自动关闭等等，是这些操作改变了订单状态。 // 那这些操作在什么时候发生呢？这个操作时间也可以理解为订单的最后更新时间，一般操作成功了就变更最后更新时间为当前操作时间。 // 事实是没人知道这个操作在什么时候发生，你无法预测用户什么时候取消订单，什么时候支付。 // 毫无疑问，这个问题无解。 // 但我们换一个思路想一下，我们是不是可以确定这个操作只会发生在：{过去某一时刻的时间点，当前时间点}，这是毋庸置疑的吧，没有会穿越未来做操作吧。 // 这有回到了区间问题。 // 还记得上面说到的 [向前推移的当前时间点]吗，这个点划过的足迹，都有可能是操作出现的位置，而宏观傻上任何操作都不可能发生在过去或是未来，只在当前此时发生，这看似哲学的问题，揭示的是事物的基本原理。所以可以这样理解，这个移动的时间点就是一只手，在向前移动的时候可能会把需要更新的订单拉到当前位置，所有的操作都是这么发生的，订单就是这样被更新的。反复理解这句话，你就能明白这个理论的重要性。 // 当我们固定区间后，但是时间点还是在继续向前移动，此时我们区间的订单有可能被拉过去，也就是说，现在我们面临的分页问题不是传统的total增多，而是减少，并且排序是不变的。 // 此时再去理解 “使用最后更新时间范围增量同步时，必须采用倒序的分页方式（从最后一页往回取）才能避免漏单问题。” 这句话的含义就能理解了 // 如果我们服务器时间比拼多多慢的话，会导致区间落后，造成获取订单永远延时，如果比拼多多快的话可能造成区间总是过前，导致总是取不到订单，所以服务器时间只能慢不能快 // 我们不漏单核心原因： // 1. 接口返回数据是按照 最后更新时间倒序的，即： order_modify_at desc // 2. 从最后一页往回取即表示是这样处理数据的：order_modify_at asc ，即 早先变化的，先处理，比较符合逻辑 // 3. 区间为 过去时间 ~ 当前时间 之间，如果分页过程中有订单发生了变化，变化订单就会向右脱离这个区间（注意不会在区间内移动，而是直接脱离），此时 total 减小 // 4. 分页过程中 total 不可能增多的原因是，因为要增多，只能从左边进入（新增订单/订单变化），但这是不可能的，因为没有人能回到过去去下单和更新订单 // 其实这样来看的话，从第一页和最后一页开始取，对于漏单是没有影响的，都可以。因为我们区间规则的原因决定了。 // 官方：“从最后一页往回取才能不漏单”核心原因： // 务必尽早的处理久远的订单，因为它们更可能发生更新（会脱离区间）。 // ！！！！！！！为了防止时间快了，这里左区间每次都向后扩展慢1分钟，模拟服务器时间比拼多多慢（暂不需要这样） ---- last update：2017-6-30 23:53:06