后端开发中哪些巧妙优美的设计

前言

这些都是我在学习八股文或者零碎知识的一些感悟，感觉一些设计确实很优美，所以记录下来

Mysql 事务管理与锁机制

事务机制和锁机制其实都是为了并发竞争而设计的，这里我想重点表达的是事务管理的设计，因为起初对于公共变量竞争问题的解决方案，一般的方法就是加锁，并且古人们也在加锁的方式上做了各种的优化，比如

• 锁的底层实现逻辑上选择——悲观锁和乐观锁

• 锁的级别把控上——轻量级锁，重量级锁，随着数据的难度升高

• 锁的附加功能上——从基础的同步锁，再到AQS也就是rentrantlock(忘记咋拼了)+condition的情况，丰富了使用锁的实际

从这个角度看，古人其实在一直优化锁的功能，因为锁这个东西本身就是一种笨办法，就是一个令牌，抢到的就通行，抢不到就等着，也就是阻塞，这对于并发来讲是不友好的，从客户端来讲就是响应慢，我得等着

那一种优美的设计出现了——事务管理

他其实也是解决并发竞争的问题，但是他设计很巧妙，底层的话就是通过快照的方式实现并发进行，采取的是一种版本号的思想，以时间为轴，按时间给你不同的版本，最后维护这些不同时间内的提交，确保最后结果是正确的，

这样设计的好处就是，确实实现了并发的效果，每个请求都拿到了他那个时间点的版本，进行修改和获取，返回数据，提高了吞吐量，所以感觉设计的如此优美

这也是为什么设计师在mysql下留下一条规矩，不允许同一个事物访问多个表，原因很简单，访问多个表的底层实现逻辑是加锁，而事务的设计之处就是规避加锁，换句话讲，访问多个表，这几个表关系到公共数据问题，必然牵扯到锁问题，如果允许访问多个表，那就打破了事务设计的规矩比如可重复读，读可提交等等，打破了事务的机制，带来的必然是事务的失效，所以立下规矩，不允许多表访问