悲观锁：

在一个事务内，查询余额使用 SELECT .. FOR UPDATE 获取锁，这样其他事务既无法读取，也无法写入，但是要注意死锁的情况，顺序编排要一致。

乐观锁：

在一个事务内，更新余额使用 UPDATE account SET ..., version = @version + 1 WHERE id = @id AND version = @version ，这样更新失败的话返回的影响行数为 0 ，可以凭此判断是否成功。

如果你的 AccessToken 不是 Stateless 的（意味着每次都要读取状态，校验 AccessToken 的合法性，判断这个 AccessToken 是否已经被撤销，或者是否已经被替换），那么 RefreshToken 就没有太大的意义。

如果你的 AccessToken 不需要读取状态（无论是数据库或者缓存），仅凭 Token 本身的签名信息就能确定它的合法性（如 JWT ），那么 RefreshToken 的存在就相当于有了一个检查点，可以在检查点确认是否还可以续签。

因此 AccessToken 的有效期应当尽量设置短一点，通过 AccessToken 访问，只要通过签名校验合法即可通行，无序读取额外的状态来进一步确认是否撤销，当 AccessToken 过期以后再通过 RefreshToken 读取额外的状态（数据库 /缓存）确认是否继续签发。

越灵活的系统就越复杂，到一定程度实际上也是在进行编程的工作，只是过去是写代码，现在是另外一种形式，至于效率高低就仁者见仁了。

抽象程度越具体化，则它的应用范围则越窄，而高度抽象的系统本身也不容易使用，需要有一定的专业知识和使用经验。作为应用层来讲，当然可以使用已经定义好的简单抽象 /组件，而这些简单抽象来自于更高层面的抽象，所以为了解决复杂性，仍然存在层次，层次越高（封装得越多），则要求更低，使用门槛自然越低。

容器化的目的是什么？更新频繁么？数据库这种软件要的就是稳定性，很少有频繁操作吧，那么容器话的目的是为了安装省事么？

@ArmstrongLiu
1 、前端 Bcrypt 是可能的，我们需要的就是把“慢”这个过程放到客户端内，代码细节可以看一下我刚创建的这个测试，需要一个固定的盐值： https://jsfiddle.net/4zdw1jab/

2 、不使用明文不仅仅只是说为了传输上的考虑，明文就是“烫手山芋”，只要生成摘要的过程是安全可靠的，其实我们根本就不需要明文。其他的顾虑包括但不限于意外的日志输出或者其他的安全漏洞，所以彻底的做法就是后端根本就不接收明文。当然这一条只是作为一个建议，如果手动模拟注册请求给后端接口发送的就是明文，那么当然也可以模拟登录用之前的明文，关于这种“非法”注册的用户，当然也就排除在正常的产品流程之外了。

登录其实就是认证，认证与授权是两个相对独立的过程。

认证解决的问题：你是谁？一般只是简单的通过标识（用户名）和凭证（密码）来确定身份。确定身份以后，认证系统一般会发放一个 Token （令牌）或者直接绑定身份信息并关联当前的 sessionid （会话，通过 cookie 传递）。

授权解决的问题：在已认证的情况下，也就是我知道你是谁的情况下，你能做什么？

关于密码：不要使用明文，后端也不要接收明文（固然有 TLS ），前端可以使用 BCrypt 慢哈希生成密码摘要，不要在后端使用慢哈希。后端生成（注册）/获取（登录）动态盐值，与前端发过来的摘要结合再次哈希一遍得到最终的摘要信息。

关于 JWT：JWT 只是作为令牌的一种承载形式，它不可伪造，不可篡改，表达了签发此令牌的真实意图，但是不要将敏感信息放进去。好处固然有，例如完全可以在不跟签发者通讯的情况下对其进行验证（签名以及有效期），但是涉及到撤销的情况下，就必须记录每一个令牌的状态（ jti 是每一个令牌的 ID ），可以建立令牌黑名单机制，虽然丧失了完全的无状态好处，但是验证这个比较轻量级。

我想说的就是可以根据场景结合混合使用不同的技术，关于安全这一块，不要自己去发明东西，大胆的使用经过时间检验的通用方法，具体如何实现只是细节问题（比如框架，亦或是自己手写），但是在流程上，概念上一定要有清晰的认知。

刚刚看到跟我这个同型号的 Sage878 ，现在只要 3984 包邮包税： https://www.smzdm.com/p/42912826/

@qwe520liao 不好意思看错了，我还以为直接使用呢，要自己做平台的话就不合适了

自建 confluence

@oieoieoie 铂富 878 ，某东国际到手 4300

@fuxkcsdn https://www.mysmth.net/nForum/#!article/WorkLife/2731643 是这个公司吗？

我用的是 LV273HUPR ，目前系统是 Big Sur ，也就是说升级完以后必定会出现这个问题吗？

DDD 里面确实有一系列指导程序编码的战术设计，但更多的是强调概念统一，减少翻译的层数，使得讨论的问题跟编码设计都能够一一对应上。

举个例子，就像一个游戏，五六个人站成一列，最后的那个人在前面那个人的背上写字，然后依次传递信息到第一个人上。人数越多，那么错误的概率也就越大。如果确实有人连字都不认识的话，那么即便只有两三个人也会导致这个问题。

DDD 就是告诉你，在一个建模的框架范围内，大家都具备这些框架的基础理论知识，然后基于这些建模框架构建出一套人人都能理解的模型，使其高度契合产品的业务需求，避免产生概念 /模型不一致的情况。

@oieoieoie 等我的咖啡机到货了在更新几张图片出来看看，估计得一两周才能到货

我记得三级等保有一条是要对入库的敏感数据进行加密，目的是为了防止被拖库以后泄漏关键数据，毕竟应用和数据库一般不在一台服务器上，同时被攻破的可能性要小得多。

不过前端加密如果不是为了防止中间人的话，那我也只能是往增加难度或者过滤掉一部分自动化探测这方面去想了，属于应用层级别的要求，不过话说回来，与其增加的复杂度相比，带来的收益微乎其微吧。

我也没太明白，只要你的终端能解密，那加密除了防止中间人还有什么其他的意义吗？还是说加密后的数据在终端是无法解密的？

@oieoieoie 大佬这个很详细了，我还有一个便携式的咖啡机，牌子是 staresso ，第三代，可以做意式浓缩，不过清洗很麻烦，成品是真还不错。的确一个好的磨很重要，其他的什么奶泡和连续出品的性能我大概率是用不到的，这些东西也是钱，性价比最高的应该是一个好磨+轻量级的萃取方法，在家里还有摩卡壶用。这次也是手痒很久了想搞一个真正的意式咖啡机。

我现在的 Mac QQ 只要点击某一个消息选项卡，就要停顿几秒钟。