躺_平

前言 我们在开发的过程中，如果一个业务操作需要本地写MYSQL数据以及对第三方系统做写操作，那么这种流程就涉及到分布式系统一致性的问题，然后并非所有系统都能使用成熟的分布式事务方案 PS:示例代码推送

前言 在众多的框架、数据库、中间件中，只要涉及到持久化，都会在性能与可靠性之间做一个抉择，而可供选择策略一般有三种：绝对性能，绝对可靠，各退一步。 本文具体就对这些思想在实践中的应用做一下讨论，经过这

事务特性之可重复读 可重复读/RR/Repeatable Read，说的是，在一个事务内，第一次执行select语句之后，本事务的后续所有查询，都会被“冻结”，以后所有select到的数据，都是第一次

事情是酱紫的 业务背景 某App上，有一个业务模块，包含：主题、帖子。 主题：字面意思，比如“吃货”，“滑雪”，“摄影”等等，都是一个单独的主题，用于聚合一些相关的话题，由用户建立（所以主题可以非常多

事情是酱紫的 开发过程中，总会遇到一些不起眼但又很恶心人的问题，比如 本地调试，有个方法要获取当前用户，所以又得去数据库翻一下，找到登陆token，放到postman里面，如果找不到这个用户的toke

前言：作为后端开发，Mysql必不可少的技术栈，因此对于其底层的学习也必不可少。在本文中，作者将通过项目中遇到的一个实际问题，来对mysql的底层原理进行剖析。 案例中涉及到很多mysql底层的优化知

背景 数据库的特性ACID大家都知道，如果单纯的只使用数据库，正常开启和关闭事务就可以了，但是如果加上了缓存，那么如果操作不当，就有可能会引发一些严重的问题 阅读本文大约花费10分钟 场景描述 假设有

事情是酱紫的 项目就是个SpringBoot工程 然后里面有一个类，有个方法加了@PostConstruct，但是由于某些外部原因，这个方法会抛异常，因此本地服务起不起来，也没办法进行功能测试（比如这