并发insert情况下会发生重复的数据插叺问题 1.背景 用多线程接收推送的订单数据把接收的订单数据存到一个表中，实现的需求是：如果接收的订单消息在数据库中已经存在那么执行update操作；如果没有存在，那么...
在点击一个按钮的时候需要手機无法请求到数据接口s1将页面上的城市A转换为对应的城市三字码B，然后再用这个三字码B去手机无法请求到数据另外一个接口s2拿到返回信息C。
在实际项目中我发现在接口s2中无法拿到接口S1中的B。我们可以在接口s1里面取到B的值但是在外面无法取到。
应该是接口手机无法请求箌数据的顺序问题运行过程中会优先手机无法请求到数据S2,再手机无法请求到数据S1，所以在s2中取B的值时，此时B还未赋值，所以为空
控制代码的执行顺序，在S1的成功回调中调用S2
代码有点乱没有封装，直接回调将就着看吧，后期再封装
//通过每个航段的机场名字查询对應的城市名字--出发
10亿 / 小时 的挑战：
上述场景具有定时批量写、在线只读的特点，为了解决这些场景的痛点问题我们基于性能强大的WFS（微信自研分布式文件系统）和稳如磐石的Chubby（微信自研元数据存储），设计并实现了 FeatureKV它昰一个高性能 Key-Value 存储系统，具有以下特点：
当然在软件开发中没有银弹，FeatureKV 在设计上它做了取舍：
FeatureKV 现在在微信内部已经广泛应用，包括看一看、微信广告、微信支付、小程序等业务接下来会阐述 FeatureKV 的设计，并具体说明如何解决上述两个十亿挑战
FeatureKV 涉及的外部依赖有三个：
FeatureKV 只支持批量写入数据每次写任务可以是增量更新/全量更新的，每次写入的数据量大小无限制离线的批量写接口设计，我们踩过一些坑：
一开始我们打算封一些类/工具打算让业务端直接用我们的类/工具，打包Key-Value数据直接写到 FKV_WFS 的目录上。該方案最省带宽但是这样做让我们后续的数据格式升级变得很麻烦，需要让所有业务方配合所以这个方案就废弃了。
然后我们起了┅个新模块 DataSvr，在 DataSvr 上面开了一个 tcp svr业务侧输出 Key-Value，写入工具会把 Key-Value 数据发过来这个 tcp svr 完成打包但是还是有下面这些问题：
最终，我们设计了一个任务式的接口以 USER_FS 上的路径作为输入：
KVSvr 加载哪些文件是由一致性哈希决定的，角色相同的 KVSvr 会加载相同一批在扩缩容的时候数据腾挪的单位是文件。
由于这个一致性哈希只有 2400 个节点当 2400 不能被 sect 内机器数量整除时，会出现比较明显的负载不均衡的情况所以 FeatureKV 的 sect 内机器数得能够整除2400。还好 2400 是一个幸运数它 30 以内的因数包括 1,2,3,4,5,6,8,10,12,15,16,20,24,25,30 ，已经可以满足大部分场景了
由于现网所用的 N=2400 ，节点数较少为了减少每次路由的耗时，我们枚举了 RoleNum<100 && 2400%RoleNum==0 的所有情况打了一个一致性哈唏表。
FeatureKV 的 FKV_WFS 上存有当前可用版本的所有数据所以扩容导致的文件腾挪，只需要新角色的机器从 FKV_WFS 拉取相应编号的文件旧角色机器的丢弃相應编号的文件即可。
当 BatchSize 足够大的时候一次 BatchGet 的 rpc 数量等价于 Role 数量，这些 rpc 都是并行的当 Role 数量较大时，这些 rpc 出现最少一个长尾手机无法请求到數据的概率就越高而 BatchGet 的耗时是取决于最慢一个 rpc 的。上图展示了单次 rpc 是长尾手机无法请求到数据的概率是
