在分布式架构大行其道的当下，如何解决分布式系统中各子系统事务一致性的问题也成了一个核心难题，由此诞生了诸多分布式事务的解决方案，本文也将围绕分布式事务这个核心主题向大家介绍分布式事务概念、原因及常见的解决方案如 2PC、3PC、TCC、本地消息表、MQ 事务消息、Saga 事务。
之前面试的时候问过候选人一个问题——“如何设计一个通用的签到系统”。说实话彼时只是看过一些网上的签到业务相关的博客，觉得这个功能跟在公司做的会员营销业务域关联性挺大的，加上之前也没接触过类似的业务，同时日常生活中用到的一些APP都有类似的功能，所以挺感兴趣的。
上一篇 我所理解的Redis系列·第2篇·位图(Bitmap)详解 中介绍了 Redis 位图的基本命令以及基于 Spring 的 RedisTemplate 实现的 Bitmap 工具类。但是在基于 Redis 位图设计通用的签到系统过程中，还发现了另一个问题：怎么才能让前端展示一周/一个月中用户的签到记录？
在前几天想要写个基于位图(Bitmap)实现的签到系统时，忽然发现自己不太清楚位图的具体操作命令，之前也从来没有有过相关的实操经验，于是才有了本文。本文记录了位图的实现原理、原生命令、应用场景以及包装后的位图工具类等。
中介者模式（Mediator pattern）顾名思义，就是充当了中介的角色，中介就是架起了消费者与开发商之间的桥梁，消费者无需知道开发商具体是谁，开发商也无须知道消费者具体是谁，他们都通过中介者来完成交易。
解释器模式（Interpreter pattern）是一种不太常见的设计模式，但事实上在某些需求的实现过程中，我们或多或少会借鉴到解释器模式的思想，今天就用支付宝的会员成长体系来演示解释器模式的应用场景。
今天要跟大家聊的是命令模式（Order pattern），这种模式其实很好理解：每一个指令所完成的行为都是不一样的，为了减少 if-else 判断，同时也是为了将命令请求者与执行者解耦，所以才引入命令模式的概念。
不知道大家小时候有没有玩过经典单机游戏，特别是一些小而美的 RPG 游戏，如金庸群侠传、口袋妖怪等等，由于通关游戏需要很长的时间，所以这些 RPG 游戏都会提供存档的功能，让玩家能够休息一会，明日再战。而下次进入游戏读取存档即可接着上次的画面继续游玩。
访问者模式（Visitor Pattern）是一种不太常用的设计模式，同时也相对较难理解。访问者模式常用于分离对象数据结构与行为，它能为一个已存在的类新增新的行为同时无需对类进行修改。
在日常开发中，迭代器模式（Iterator Pattern）是我们时时刻刻都在用，但却存在感最小的一种设计模式。对于普通的 Java 业务开发者来说，我们基本上不会去单独写一个迭代器模式，这是因为大部分常用的容器都已经提供了迭代器模式的实现了，如 List、Set 等等。
基于SpringBoot的三味书屋图书商店后台
基于 SpringBoot2.0 | MyBatis | MyBatis-Plus 实现的 RESTFul 管理系统
基于PHP和Oracle开发的校园交友网站
针对资讯的用户建模和个性推荐系统
yapi idea 上传插件,快速生成文档
基于Java设计开发的一款小游戏