2018新年计划
拖了这么久才开始进行自己的2018年的新计划，这点也是给自己的警钟。。。在安逸区太久了，对自己的要求很多都放松了。。
今年要紧迫起来，体验过程中的同时，也要把事情做好，不要半途而废。。
今年的主题是，尝试和坚持。。
工作上，在架构上做一些东西出来，容器化，调度上去尝试了解一些东西，语言上，学习一下函数式语言，继续生挖golang，注意最新几个版本的变化，看能不能抓住主线。。机器学习上，通过考试和各种途径，入个门；然后，看是否能在广告上，做些东西出来
换工作？
客户端部分，小程序，看能不能捡起来，把以前没做完的，尝试地做完。。业余项目上，关于android游戏端，是不是可以把流程走完？尝试做下side project
blog部分，恢复更新，同时，保证更新的频率，周末要多写写。。在技术上多写些读后感之类
算法和业余项目上，leetcode，找个时间，定个计划，刷起来。。project52，也要抽时间弄，不要半途而废。。
生活上，今年的目标是泰国和南方(杭州或者福州)，游记要及时补充。。
身体锻炼上，恢复之前的锻炼，减肥。。。今年的目标是32，腹肌也要锻炼出来。。
感情上，还是傻瓜一个吧，身体上，尽量吧，或许自己不是很适合。。战战兢兢，小心翼翼吧。。
摄影上，把课程学完，多出去拍摄一些东西出来；吉他上，学习下指法，献给爱丽丝。。
电影和书上，把握节奏，逐步地推进下去，给自己静下心的一段时间。。
其余方面，养只仓鼠，尝试去照顾一下小动物；买个手柄，锻炼一下自己的手残，把尼尔通关
投资上，在股市上小投资一些，每天一顿早饭钱，看年底能不能把PS4赚出来。。其余方面，把外债都还清，加强资金的把控。。
所说的一定要保证能保证，不要总是眼高手低。。
做时间的主人，把时间好好地安排下，延缓自己的拖延症。。
无状态化与容器化
很多应用拆分成微服务，是为了承载高并发，往往一个进程扛不住这么大的量，因而需要拆分成多组进程，每组进程承载特定的工作，根据并发的压力用多个副本公共承担流量。
阻碍单体架构变为分布式架构的关键点就在于状态的处理。如果状态全部保存在本地，无论是本地的内存，还是本地的硬盘，都会给架构的横向扩展带来瓶颈。
所以要讲整个架构分成两个部分，无状态部分和有状态部分，而业务逻辑的部分往往作为无状态的部分，而将状态保存在有状态的中间件中，如缓存、数据库、对象存储、大数据平台、消息队列等。
容器和微服务是双胞胎，因为微服务会将单体应用拆分成很多小的应用，因而运维和持续集成会工作量变大，而容器技术能很好的解决这个问题。然而在微服务化之前，建议先进行容器化，在容器化之前，建议先无状态化，当整个流程容器化了，以后的微服务拆分才会水到渠成。
幂等的接口设计
由于存在重试的机制，就需要接口是幂等的
接口分为查询、插入、更新、删除等操作。
对于查询接口来讲，本身就是幂等的，不用做特殊的判断。
对于插入接口来讲，如果每一个数据都有唯一的主键，也能保证插入的唯一性，一旦不唯一，则会报错。
对于更新操作来讲，则比较复杂，分几种情况。
一种情况是同一个接口，前后调用多次的幂等性。另一种情况是同一个接口，并发环境下调用多次的正确性。
为了保持幂等性，往往要有一个幂等表，通过传入幂等参数匹配幂等表中ID的方式，保证每个操作只被执行一次，而且在实行最终一致性的时候，可以通过不断重试，保证最终接口调用的成功。
对于并发条件下，谁先调用，谁后调用，需要通过分布式锁如Redis，ZooKeeper等来实现同一个时刻只有一个请求被执行，如何保证多次执行结果仍然一致呢？则往往需要通过状态机，每个状态只流转一次。还有就是乐观锁，也即分布式的CAS操作，将状态的判断、更新整合在一条语句中，可以保证状态流转的原子性。乐观锁并不保证更新一定成功，需要有对应的机制来应对更新失败。
容器的技术部分
容器运行时
看起来是隔离的技术，namesapace
用起来是隔离的技术，cgroup
当容器平台规模不是很大的时候，Docker Swarm Mode还是比较好用的：
- 集群的维护不需要ZooKeeper，不需要Etcd，自己内置
- 命令行和Docker一样的，用起来顺手
- 服务发现和DNS是内置的
- Docker Overlay网络是内置的
当规模比较大，应用比较复杂的时候，则推荐Kubernetes。
可以尝试一下docker swarm的方式来进行
设置配置中心
配置中心最基础的场景：
客户端和服务端保持一个长链，当在后台操作配置时，会把这个配置以 K/V 形式存储，然后通知 Procesor，后者拿到 K/V 之后把它推给客户端，整个过程就完成了
保存K/V时，额外存一个flag字段，表示是否已经成功发送给客户端
多份配置的处理
- 存储
一个设备的 K/V 对通常不会超过 100 项，每对 Size 不超过 1K，也就是一台设备对应的大小上限为 100K 左右，假如设备数为 100 万，就需要 100G 的磁盘空间
采用索引加上组合的方式，
参考一下 Go 语言里 Slice 的设计，Slice 内部使用了一个数组，但可以指定使用该数组的哪一部分，其实就是索引。
这样某个 Key 如果有新的 Value 了，只需在对应的 Key 后面 append 即可。此时需要同步更新设备的索引，这块可能花一点时间，如果数据都在内存的话其实也还好（由于只是存索引，因此这些数据量内存 hold 得住），持久化可以异步进行。
流量
对数据进行压缩
例如使用lz4,lzma等
使用diff
Diff 的话一种处理方式是把 K/V 的索引放到客户端，然后比对两个索引的 Diff，再把真正的 Value Diff 下发到客户端进行合并。这样就会有一个问题，客户端需要上报它当前的配置中心的索引值，这就涉及到上报时机。服务端在得知更新后，主动向客户端要当前保存在客户端的 Config Indexes，对比之后再发送 Diff
同步策略
多设备
简单的处理可以用令牌桶算法：桶里的令牌数代表服务器当前的承载能力，每次请求进来消耗一个令牌，如果令牌消耗完了，请求直接拒绝，等服务器缓过来了，再往桶里加令牌。
多维度
维度的更新
上面可以看出，该配置针对每个duid都会有一些配置，而不是我们传统意义上的针对app_key部分，这样，可以确保每个用户都能收到
2018碎碎念
或许是自己习惯了单身，亦或许是有些门不当户不对，有时候莫名地会感到很沮丧，也在疑问自己为什么会去打破自己的坚壳。。
骨子里还是自卑吧，也不想改变，顺其自然地发展吧，做到自己能做到的一切，至于做不到的，及时讲吧。。不要怕让人失望，为自己一些。。
时间上，要好好想一想，不然都没有提升，该做的东西要逐步地实施。。
每次都担惊受怕，哎，自己估计还是不行，有时候会因为躲过而庆幸？哎，自己还是像个傻瓜一样，啥都不会。。
关于计划和总结，要抓紧时间弄一下，时间上做下规划。。
顺其自然吧。。
大姨妈又没准时地来，哎，每次都担惊受怕，自己还是不行，后面，坚持戴吧，太难受，太煎熬。。
计划和总结要弄了，不要再拖了。。
有时候，想想都没做好心理准备，其实挺可怕的，整个人生和计划上，都错乱了。。
顺其自然吧。。身体健康，努力向上。。
大姨妈还是来了。。有点长吁一口气。。拖的计划，感觉又可以往后延了。。苦笑。。
锻炼和身体部分，还是要继续坚持下去。。慢慢调整状态
同时相关的时间表部分，也要列出来。。。新计划，要逐渐地实施起来。。
感觉自己有点变得不像自己，努力找到自己，找到自己的定位。。