后端开发除了增删改查还有什么_-大宽宽

我们先从一个简单的增删改查开始，把业务慢慢变得复杂，看看你要怎么做。

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

……

把眼界放开一点，你会发现有无数的问题可以解决。这些问题搞来搞去其实也能回到增删改查上，但怎么组织这些逻辑，给出可行靠谱的方案才是更关键的问题。

然后你是不是发现，总有几个人把这些事情都想清楚了，把一个巨复杂的问题拆解了，然后告诉你去做其中一部分增删改查？

评论区

不好意思: 说的很好，面试这些内容的话会比八股文更有深度和广度 👍🏽132 💭北京 🕐2023-05-04 01:17:20

│ └── 刘怡超: [doge]你面高级的不就是这些百度不到的经验 👍🏽21 💭广东 🕐2023-05-28 10:37:42

杨欣: 您的观点很有趣问题的识别，拆分，到最后的解决确实，最难的的问题的识别得结合业务，开发的实际，知识与经验，业务与架构。多维度的思考考量，才能把问题给准确无误的找出来提出来。问题的拆分的话，难点是能不能对问题有一个整体的认知。不然很难达成拆分。能拆分的话，接下来要做的就是对问题进行不断的拆分细化，分类总结。最后，给出个可行的解决方案。问题的解决的话。说实话，到有解决方案了。最低要求是能准确的领悟，做出来的成果尽量无偏差高点的要求是能明白为什么这么做，然后做好 👍🏽40 💭浙江 🕐2023-05-04 00:15:13

皇家救星: 抽象有助于理解事物，但是也容易忽略对事物本身复杂度的认识。curd概括起来就四个字母，但是光插入，就要分登记到内存，数据库，文件，消息队列中间件的区别。还要考虑失败与回滚，断电异常，多方事物等。 👍🏽26 💭广东 🕐2023-05-08 08:29:16

│ └── zyqlist: 其实就是看你怎么理解，你可以说不是，因为很多细节，也可以说是，概括起来就是curd 👍🏽1 💭广东 🕐2024-07-17 18:30:23

watero: 几个业务也能被大厂玩出花来[doge] 👍🏽20 💭广东 🕐2023-05-04 01:32:16

INN: 我经常看b站的时候,发现有"当前视频1000人+正在观看"这个功能,它背后的原理应该和这个存储查询点赞的原理应该是一样的吧? 如果是我设计的话,我用两张表来存储点赞关联及被点赞的统计量user_work表存储用户与作品的点赞关联,该表中的某条记录则表示某用户点赞某作品,通过对它的insert/delete实现点赞和取消赞popular_work表存储热门作品的点赞统计数量,设定一个字段存储数量级枚举值(1000+ 、10000+、10w+等)当请求查询某作品的点赞数量时,先查询popular_work表,若有记录,则返回枚举值;若无记录,则select count(1) user_work where …同时设置定时任务来更新 popular_work的作品火热程度缓存中间件的使用不缀述我这个思路ok吗? 👍🏽16 💭北京 🕐2023-05-04 02:28:21

│ └── 僵尸先生: 为何不用redis？我感觉如果表操作的话性能会很差 👍🏽1 💭广西 🕐2023-05-04 08:51:14
│ └── 周公喊我去下棋: 感觉你这套已经能抗一个不小的网站了。不过数据量更大了可能还要考虑一下：用户与点赞的数量较多的情况下，怎么分库缓解压力；如何低成本发现热门作品并放到popular_work；定时任务更新其实要扫整个user_work表，如何避免；定时任务的频率如何控制等问题[思考] 👍🏽10 💭北京 🕐2023-05-04 09:15:21
│ └── 李兆星: 用RDB的好处是持久化和精确，但缺点也很明显，TPS很低（对比redis单机十万QPS）而从这个场景来看，点赞和取消其实只是一个KV就能解决，不需要用到RDB这么重，何况还会涉及事务可见级别至于如何统计点赞人数，从KV的角度其实是一个前缀范围查询的事情，这个和select count其实是等效的；更有效的做法是缓存/预计算，也就是每次点赞和取消的时候都更新一下这个统计，由于是KV，代价很小. 比如redis的SCARD命令，代价O(1) 👍🏽20 💭北京 🕐2023-05-04 11:00:41
│ └── 碎乐: 怎么分表是大问题，还有就是点赞和评论的通知推送，至于热门作品这些，你有底层数据了，定时任务生成热门作品单独一张统计表压力也不会很大 👍🏽0 💭上海 🕐2023-05-04 14:21:52
│ └── 祖与占: 微博计数器的设计(下) 👍🏽2 💭日本 🕐2023-06-15 14:40:16
│ └── Clouwer: 客户端有发心跳或者有发关闭视频之类的吧，点开视频和关闭视频能通知到服务端，关闭视频一个用到历史记录上(你只有关掉视频才会出现在历史记录里)，一个用到这个正在观看里，正在观看里最多存一个峰值，放内存里也不怕丢吧 👍🏽0 💭广东 🕐2023-09-19 20:54:53
│ └── qiudaoyu: 要是我的话，直接用户进入视频时把uid加入redis的set，退出时删除，统计人数还方便。应届生还没入职，这种数据没必要持久化吧，不知道这种方案会不会有啥毛病[捂脸] 👍🏽0 💭安徽 🕐2024-07-07 12:18:41
│ └── qiudaoyu: 就是web端好像不太好知道用户有没有在看视频 👍🏽0 💭安徽 🕐2024-07-07 12:21:45
│ └── VxkqCzWQ: 前端可以判断用户是否切换页面的 👍🏽0 💭浙江 🕐2025-03-03 09:09:28

段林: 你提出的这些问题如果能附带解答就好了，我愿意为此付费。现在公司产品是地端部署的tob系统，这块内容了解的真不多，挺感兴趣的。 👍🏽18 💭安徽 🕐2023-05-08 08:36:58

│ └── 大宽宽: toB超复杂[飙泪笑] 👍🏽10 💭北京 🕐2023-05-08 09:29:37
│ │ └── 只因舍舍长: 对于B端复杂业务逻辑和需求，有什么经验和心得吗（架构上或者代码上的）[好奇] 👍🏽0 💭广东 🕐2023-08-20 10:02:31
│ │ └── 夏末: 做好mock，哈哈哈 👍🏽0 💭重庆 🕐2024-06-10 18:10:59
│ └── 卢梭罗: 可以交流 👍🏽0 💭北京 🕐2023-05-29 21:20:04

今年ggg: 来个前端模仿这老哥说一下技术难度在哪[飙泪笑] 👍🏽17 💭广东 🕐2023-05-05 12:23:44

│ └── 青橘红柚: 交互的改进是永无止境的，这就是前端的意义。从最开始输入命令行到图形化操作软件。电脑本质是一种工具，工具如何顺手，也就是你如何操作页面的流程更加流畅，符合直觉。还有就是借助新的输入工具，比如鼠标的诞生，或者vr的出现，都会让显示诞生更高的需求。 👍🏽8 💭辽宁 🕐2024-07-31 12:08:37
│ │ └── 西风烈: 你说的是前端技术的发展，不是前端开发平时会遭遇的问题。 👍🏽1 💭上海 🕐2024-08-11 08:12:50
│ │ └── 晨风: 诞生新的方式吧， 👍🏽0 💭广东 🕐2025-02-22 18:15:10
│ └── SoulDee: 技术难度看业务，在管理系统这种场景就是后端比前端复杂，核心业务在后端，但如果是强交互的图形编辑和富文本这一类，业务核心在前端的，那技术难度就在前端（顺便，前端不是只有web端，桌面应用也属于前端）。说的再简单点，就是你看看哪个端做差点也能用的哪个就有技术难度，管理系统这种前端做的垃到也能用，只是体验拉抱怨多，图形编辑你前端拉了还编辑个啥。 👍🏽0 💭福建 🕐2024-10-21 13:13:35
│ └── 乳鸽菌: 从零开始编写低代码框架。。。 👍🏽0 💭广东 🕐2024-11-15 09:07:50

金风: OK 给大家解惑了 大问题一：在实体类上做注解，然后通过AOP 进行对字段与数据库加解密 看ORM框架 如果是HB用@Conver然后去实现 AttributeConverter 接口 如果是Mybaits 这个用的不多 忘了 去百度吧 核心思路就是 实体类上对字段加标记 然后数据库字段和实体字段 进出转化。小问题1：加密正常做，解密稍后一起处理。字段照样用 @Convert，但只“标记”不真实调用 RPC， 然后加密的东西交给上下文处理 ，统一解密 然后在处理。小问题2，最好不要做降级处理，关于数据信息 如果做降级处理，破坏数据的一致性和完整性。 明文返回也会有问题， 一般更好的是做重试机制和熔断机制。但一般项目上更多的是直接报错 然后运维人员接入。小问题3. 原生SQL部分映射，回答这个可能不错，但个人认为一般不是在靠这个。更多的可能考在 分离实体做懒加载，查询时，如果不需要敏感数据，则不用触发懒加载大问题二： 本质上还是在考 读写一致 一般都是双写 先旧后新，写入尽可能原子化，如不能同时成功则需要回滚或者触发补偿逻辑。 一般最好的解决办法就是本地事务+异步补偿。 先写本地事务，在记录 后台异步线程去同步 KV 存储，补偿的话，在写操作中，如果检测到 KV 存储写失败，可以将该笔写操作的关键信息记录到补偿表或消息队列中，由后续专门的补偿任务定时扫描、重试写入 KV。。小问题1 不建议降级，解决办法还是同上，双鞋 加补偿。用字段做标记已同步未同步。 读操作的兜底逻辑 先kv 后数据库。小问题2 主备分离 ，核心还再说双写 加补偿。大问题三： 唯一标识就行 数据库里面建立约束 也可以请求的候可以使用消息队列或补偿日志设计，确保同一请求只会被消费和处理一次。小问题1 用 条件唯一索引 数据库层面对未删记录做唯一性约束；再配合应用层的事务和并发控制，可以基本保证在软删及恢复的过程中，同时只有一条“未删除”的记录好了 只看前几题 后面懒得看了，其实我会问 比如第一个 我可能会反问他，什么业务场景需要对某个字段进行加密 ， 公司的业务体量需不需要做如此多此一举的操作。贵公司目前现有有没有实际案例。这样设计了对用户有什么好处。数据保密对于B端系统有没有必要性。其实很多问题都是围绕着业务场景来展开的。 比如你只有100-500人的公司 公司的总业绩连10个亿都没有 考虑这些玩意 全是多余 👍🏽4 💭浙江 🕐2025-04-16 11:36:12

小欧: 你说的对。但是大多数后端不会这么复杂，没有那个能力，也消费不起那么多服务器。客观回答这个问题就是一定数据量下前端难，中大数据量后端难。 👍🏽8 💭广东 🕐2023-10-21 01:26:25

Regex: 有点意思,值得思考.先点赞! 👍🏽6 💭加拿大 🕐2023-05-04 05:37:45

松仁: 好多都有单独的团队来做，比如一般大厂都自己设计一个单独的kvservice，等等来存储上亿级别的kv对，同时又在上面增加了扩展比如consul+raft满足一致性，数据分片满足可扩展，配置中心满足动态迁移等等，真要都设计下来一般很复杂。也一般很少有请求跨机房查询，除非是一个数据中心全不可用的情况下。 👍🏽5 💭北京 🕐2023-05-11 13:00:37

樱冥殿: 很多问题本身就是一个单独的服务要解决的，比如鉴权系统，整个和现在aws的iam一样啊。[微笑] 👍🏽1 💭美国 🕐2024-02-05 13:51:33

清音巡绫: [思考]想学这些 👍🏽2 💭广东 🕐2023-05-27 17:38:18

武当王也: 越看业务越熟悉，居然是东家[捂脸] 👍🏽2 💭湖南 🕐2023-05-18 02:16:40

│ └── 大宽宽: [飙泪笑] 哪里看的比较熟悉？我以为大厂都这样 👍🏽0 💭北京 🕐2023-05-18 11:09:27
│ └── 武当王也: 你说的这些业务场景[捂脸]之前在公司搞飞书云文档那块 👍🏽4 💭湖南 🕐2023-05-18 20:45:24
│ └── 大宽宽: 6666。最复杂的业务：） 👍🏽0 💭北京 🕐2023-05-18 21:37:44

to change: 软删除应该可以做到。把业务中不能重复的一个或多个字段做为唯一索引，这就是普通的利用数据库唯一约束的方式。但有一个致命问题:当软删除了某个记录后，再次插入相同的字段的记录显然会失败。这时候可以增加一个新字段，把它也加入之前的联合索引上。当我们插入一条新纪录时，都对这个字段赋予一个相同的默认值，这样两条相同的记录插入就会冲突。删除的时候不仅设置deleted字段，同时把这个字段赋予一个不能和已有记录重复的随机值，这样就能够对已经被删除多次的记录进行再次插入了。[飙泪笑] 👍🏽1 💭江苏 🕐2023-05-04 09:40:38

│ └── L.excubitor: 或 删除时，把唯一约束字段拼接系统时间唯一值，这样就不会重复了 👍🏽3 💭广东 🕐2023-05-04 12:44:51
│ └── 于小白: 删除的时候把id存到deleted字段就ok了 👍🏽2 💭陕西 🕐2023-05-05 13:28:32
│ └── 大烧饼: 也可以把字段设null 吧 👍🏽0 💭广东 🕐2023-05-06 02:06:45
│ │ └── 段林: oracle里，唯一索引上不允许有多个null 👍🏽0 💭安徽 🕐2023-05-08 08:33:49
│ └── 李壮志: 其实也得看删除的业务场景，如果是不太多的情况下，个人觉得不如直接弄个备份表，或者把当前行直接序列化后存到另一个表里去，这样保证主表数据唯一，在需要时，再反序列化回来，这样一个备份表就可以解决所有的软删除记录的问题。 👍🏽2 💭北京 🕐2023-08-16 13:53:40
│ └── Forest10: 不需要 设计deleted为long 默认是0未删除，剩下删除就把当前时间戳放进去就可以了 👍🏽0 💭上海 🕐2024-11-25 20:39:04

乌拉乌拉: 你要聊代码，那我可起劲睡不着了 👍🏽1 💭河南 🕐2023-07-22 03:55:27

手可摘星辰: 然后你是不是发现，总有几个人把这些事情都想清楚了，把一个巨复杂的问题拆解了，然后告诉你去做其中一部分增删改查？ 这句话就能看出真的理解透了开发了 👍🏽1 💭山东 🕐2025-04-23 15:31:08

r4mind: 为什么评论区这么多人问些东西在哪学？这不是在公司待久一点自然接触到的吗？工程方案很多时候就是自己悟道，哪有那么多像教科书一样的东西学？中国程序员到工作了还是做题思维。 👍🏽1 💭上海 🕐2023-09-15 08:39:01

│ └── BackTech: 怎么是要去工作就要面试这些问题。。 👍🏽0 💭海南 🕐2024-01-18 01:39:39
│ └── 霜之哀伤: 因为有些人还是在校学生，去哪接触这些场景？实习基本是打杂，只能自己学。而且秋招时面试官可不会因为学生身份就不问系统设计了[大笑] 👍🏽2 💭广东 🕐2024-07-31 03:16:21

世人皆苦: 确实，大多数底层就是增删改查，但是业务上的鲁棒性(是否并发、是否需要高性能、是否需要加锁、是否异步等)才是你重点开发和思考的部分，如果你的开发只让你觉得只有crud，要不是公司的问题，要不就是自己的问题 👍🏽1 💭北京 🕐2024-01-23 09:48:17

郑宇大哥: 照你这么说操作系统也就是个增删改查而已咯 👍🏽1 💭浙江 🕐2023-09-18 10:03:23

│ └── 大宽宽: 不然你以为呢 👍🏽6 💭北京 🕐2023-09-18 10:25:44
│ └── Sjtukk: 冯诺依曼计算机本质就是指令+数据，任何操作不都是对数据的增删改查？ 只是当系统规模上去之后，怎么快速准确地增删改查罢了，但里面涉及的内容非常复杂，安全性问题，数据一致性问题，查询效率问题等等 👍🏽0 💭江苏 🕐2023-11-11 02:09:06

单边耳环: 第三条我还遇到了、情况是这样的、一个登录接口、逻辑是先查找用户身份、如果有就直接登录、没有就插入一条数据、试运行的那天、有个用户登录不上、检查发现是同时插入了两条数据、这个情况我一直以为是要加锁的问题、 👍🏽0 💭广西 🕐2024-08-19 04:16:26

晨夕: [大笑] 👍🏽0 💭上海 🕐2025-02-18 16:14:17

chaleaoch: 如果有答案就更好了. 👍🏽0 💭日本 🕐2024-07-29 16:50:34

mark: 你是哪个大厂的啊，我们业务很相似啊，我组做im，关注的[抱抱] 👍🏽0 💭重庆 🕐2025-02-03 08:57:07

SoNight: 求解答 👍🏽0 💭湖南 🕐2024-12-31 11:20:34

zjxnxyslabxoamx: 很有帮助，谢谢！ 👍🏽0 💭江苏 🕐2024-12-02 12:08:45

soho: 问题的答案是什么 👍🏽0 💭江西 🕐2024-11-30 20:51:44

还是那个你: 答主要是能配上答案就更好了 👍🏽0 💭上海 🕐2024-10-25 00:52:00

matlab小王子: 蹲一个完整版本的参考答案 👍🏽0 💭美国 🕐2024-06-21 12:56:09

HAAAAAAAPY: [蹲] 👍🏽0 💭湖北 🕐2024-08-27 10:38:47

可口可乐了看看: 哼嗯，宽佬你这不为难人嘛， 👍🏽0 💭江苏 🕐2023-05-06 00:02:50

│ └── 大宽宽: 这些都不是什么高深技术，都是有最佳实践的烂大街的东西 👍🏽1 💭北京 🕐2023-05-08 09:30:45
│ └── 狂人的芝士: 大佬，这种特定业务场景的最佳实践去哪学呀，我是新手后端[流泪]，遇到稍微难一点的需求就抓瞎了[飙泪笑] 👍🏽1 💭湖北 🕐2023-05-26 00:22:16
│ └── 大宽宽: 都是爬过来的 👍🏽0 💭北京 🕐2023-05-26 20:39:52
│ └── 只因舍舍长: 有解决方案嘛[大哭] 👍🏽0 💭广东 🕐2023-08-20 10:04:02
│ └── 请叫我张北海: 你挨个问题百度，然后顺着线索往下看。一天看一个，都看会了。就像答主说的，这都是有最佳实践的东西。学这种经验，最大的难度不是解决方案，是没遇到过自己怎么能想到(自己问自己问题)。最难的一步答主都做了，剩下自己学就行了[酷] 👍🏽0 💭北京 🕐2024-04-17 16:52:27

强哥叨逼叨: 哈哈，如果是你说的这种增删改查那确实没毛病，本来编程就是针对数据就行操作的过程。而这个操作不就是增删改查吗？只是说编程在为了实现增删改查能成功的基础上，又做了一系列的操作来保证这些过程能够顺利的执行。 👍🏽0 💭福建 🕐2025-06-21 22:14:23

管伟: 对，这就是程序设计中的“设计”，真正难的点是这些，而不是编码。 👍🏽0 💭河南 🕐2024-10-21 15:03:38

氧化性百万酸面包: 师傅别念了 👍🏽0 💭新疆 🕐2024-06-10 23:55:11

siri ray: 很多时候其实已经在做这个东西了，但是自己没用意识到[捂脸] 👍🏽0 💭江苏 🕐2024-04-03 20:56:43

喵喵牛牛: 赞 👍🏽0 💭广东 🕐2023-11-14 22:26:09

梦境渐现: 所以拿多少钱办多大事。前端后端各有各的难点，不用相互对立，都是小卡拉米，谁也别笑谁。当务之急是，勤学多用活用勤思考。 👍🏽0 💭上海 🕐2023-10-11 16:25:24

000: 這東西比刷題實際多了，可惜現在風氣… 👍🏽0 💭中国台湾 🕐2023-10-10 13:08:57

│ └── 那夏: 台湾也这么卷吗 👍🏽0 💭陕西 🕐2023-10-13 08:52:20
│ └── 伯约: 不卷的,我上家公司台企,研发总部在台北,比较轻松 👍🏽0 💭广东 🕐2023-10-13 15:12:06

洞壁观影: 业务场景和性能导致技术方案的选型和设计。弄清楚场景选择最合适的组件或方案。大的说架构设计要符合场景，接着就是按照需求拆解业务领域。后端重在设计，重在设计质量和代码质量。总结：业务场景的复杂度存在的前提下，比拼的是设计能力（绝对不是增删改查）。 👍🏽0 💭上海 🕐2023-08-24 13:11:53

甲骨文人: 都是一些毫无意义别人不愿意做的脏活累活，一到35岁就滚蛋 👍🏽2 💭江苏 🕐2024-12-04 23:14:55

└── mark: 你考研考上没有，看起来有点🍬 <span class="small-blue">👍🏽0 💭重庆 🕐2025-02-03 09:30:34</span>
└── 说真话就被封: 嘿嘿 <span class="small-blue">👍🏽0 💭天津 🕐2025-04-03 15:43:08</span>