后端开发除了增删改查还有什么？
我们先从一个简单的增删改查开始，把业务慢慢变得复杂，看看你要怎么做。
- 需求上需要对部分字段加密，读取时解密。又希望这个逻辑能尽量收敛，避免业务层代码遍地都是加解密，同时又能收敛和管控加密的算法，强度，秘钥等。要怎么做？进一步的：
- 如果用来加密的服务不是自己开发的，行规要求必须引入第三方服务，每次存储都得带一次rpc怎么办？
- 如果用来加解密的rpc临时失败了，要降级吗？还是直接报错？
- 有部分获取数据的请求根本就不需要那条被加密的字段，只需要其余几列。能把加解密优化掉吗？
- 用mysql太慢了，希望改成某种序列化KV，过渡期不能停服，要双写同时又要能保证数据一致要如何做？进一步的
- 改成了KV，但KV可能挂，能临时用mysql降级先存着，KV恢复时再写回来。能保证数据不丢吗？
- 以上问题如果发生了跨机房，如何设计数据的访问模式呢？
- 插入时可以保证幂等吗？如果有多次并发的请求从端上发过来（端上可能会重试，可能会bug抽疯），后端能保证只写入一条数据吗？进一步的
- 如果这个数据需要支持软删，软删了后还得可以恢复（比如某种回收站功能），能保证同时只有一条”未删除“的数据吗？insert和update set deleted=0能很好的配合不出乱子吗？
- 两个机房，做主从复制。无论如何主从复制必然有延迟。如果主库机房写入一条订单，还没复制给从库，主库机房挂了怎么办？从库无法得知主库有这么一条记录，切主可能会导致数据丢失（以及接下来的用户的投诉和巨额赔偿）还是说，这个订单必须得到了从库才算”成功”，怎么实现呢？
- 一个共享文档，十几个人同时改一行文字，这个改的文字最终会变成什么样呢？改动生效的规则和时序怎么算呢？
- 一个IM，一堆人在同一个群的不同的端上发消息，谁先谁后呢？
- 可以用序列号来搞，但这个序列号怎么生成呢？
- 单机可以抗下吗？序列号生成器挂掉怎么办？
- 做一个鉴权系统，需要存取一堆鉴权规则。鉴权时读取即可实现鉴权，比如用户A能不能访问一个文档X。问题是A可能在一个组织架构里，有上级部门；上级的部门又有上级部门。任意一个部门都可以设置访问文档的规则。 如果多级部门各自设了不同的规则（能访问/不能访问），最终落到A上哪个规则生效呢？具体的逻辑怎么写？更进一步的
- 这个规则里还带有条件咋办，比如工作日10:00~17:00可访问；其余时间不可访问
- 如果规则有特殊处理咋办，比如不可访问时用户可以向上级发一个申请，审批通过后就可以访问了
- 用户又要求这个访问规则必须分多个版本。新版本审批后才能替代旧规则。怎么做？
- 大量对一个微博帖子发了很多赞，这个赞怎么存和保证准确呢？每次 select count(id) ? 进一步的
- 假如我们可以允许一定程度的不准（比如超过9999赞，不太准也可以）但要求不能偏的离谱，必须按某种时间间隔去“矫正”。这个矫正怎么触发呢？
- 如果矫正需要某种分布式定时器，这个定时器怎么实现呢？单机可以抗下吗？
- 如果机器挂了，定时规则没存盘就丢了，能不丢吗？
……
把眼界放开一点，你会发现有无数的问题可以解决。这些问题搞来搞去其实也能回到增删改查上，但怎么组织这些逻辑，给出可行靠谱的方案才是更关键的问题。
然后你是不是发现，总有几个人把这些事情都想清楚了，把一个巨复杂的问题拆解了，然后告诉你去做其中一部分增删改查？
