我说分布式事务之TCC
接触分布式相关的开发已经有一段时间了，自然绕不开分布式事务。从本文开始，我将带领大家了解常见的分布式事务的解决方案，深入原理，浅出实践，让我们在今后的开发中对分布式事务不再畏惧。
常见的分布式解决方案有：
- 最大努力通知型事务
- 可靠消息一致性事务
- TCC事务
本文我们就详细的讲解TCC分布式事务的原理及应用场景。Here we go!
Spring单例Bean与多线程深度分析
接触过Spring框架的同学们都知道Spring的bean默认是单例的，在高并发下，如果在spring的单例bean中设置局部变量，则会发生并发问题。
最近在进行开发时，错误的在单例的bean中使用了成员变量，导致多个线程大并发访问时，出现赋值错误及日志打印混乱的问题。
本文就对单例bean及多线程安全的问题做一次较为深入的探讨，也是对自我的一次反省，之后的开发中，杜绝此类问题，修正开发习惯。
详解logback.xml与logback-spring.xml的区别及联系
logback和logback-spring.xml都可以用来配置logback，但是2者的加载顺序是不一样的。
加载优先级为：
logback.xml--->application.properties--->logback-spring.xml.
logback.xml加载早于application.properties，
所以如果你在logback.xml使用了变量时，而恰好这个变量是写在application.properties时，那么就会获取不到，只要改成logback-spring.xml就可以解决。
官网的说明如下：
自己写分布式限流组件-基于Redis的RateLimter
在分布式领域，我们难免会遇到并发量突增，对后端服务造成高压力，严重甚至会导致系统宕机。为避免这种问题，我们通常会为接口添加限流、降级、熔断等能力，从而使接口更为健壮。Java领域常见的开源组件有Netflix的hystrix，阿里系开源的sentinel等，都是蛮不错的限流熔断框架。
今天我们就基于Redis组件的特性，实现一个分布式限流组件，名字就定为shield-ratelimiter。
详解ThreadLocal为何存在内存泄漏
ThreadLocal是Java中用于保证线程安全的一种措施，通过给每个线程分配一个专属的值存储空间，保证线程各自维护自己的变量，从而不会发生并发访问问题。
但是ThreadLocal是存在着内存泄漏风险的，如果使用不当，容易发生memory leak错误。
专题--分布式开发之logback输出模块日志到单独文件
首先聊聊业务开发中常见的一个问题，如何输出不同业务场景的日志到不同的文件中。
这个场景在开发过程中很常见，我们的日志文件中除了会输出业务日志，还会输出统计、监控、异常等不同类型的日志，如果都放在同一个文件中，对于可读性和问题的定位都不友好。因此将不同类型的日志分别输出，
这里以输出统计日志到单独文件这一场景进行讲解。
专题--分布式业务开发
近一个月只发了一篇文章，主要是因为这个月参与开发了一个新项目，具体细节就不说了。架构是基于分布式的，基于Dubbo的RPC交互方式，由于数据量较大（与某一线互联网公司合作开发），使用了分库分表。部署在云上，部署环境为kubernates。
说是近年来参与开发的规模最大的项目也不为过，有很多东西想写，暂时定如下几个话题，最终写一个专题出来。
自己写分布式链路追踪框架2-包装日志组件自动输出traceId
之前的第一篇文章 自己写分布式链路追踪框架1–TraceId/SpanId/ParentSpanId生成及传递 中，我们完成了trace的封装及通过HTTP进行传递的操作。实现了跨服务TraceId生成及传递，在实际生产中，要实现对业务链路的监控，常常基于日志输出TraceId，将日志收集到统一日志平台，例如ELK。
这样我们就能够基于日志平台提供的搜索功能，通过唯一的TraceId将贯穿多个服务的业务链路穿起来进行分析，甚至基于调用链路的完整性进行性能相关的监控。
同时，我们还要尽量减少TraceId对业务日志的侵入性，这时就需要对日志组件进行自定义的包装改造。
那么就跟着我的脚步，开始今天的话题–包装日志组件自动输出traceId吧。
mysql设置update时间字段自动更新
我们在数据库表设计阶段中有个最佳实践，需要在每个表中预留创建时间create_date, 修改时间update_date字段（阿里巴巴编码规约中建议命名为gmt_create,gmt_modified），数据类型均为timestamp。
其中，create_date字段在一般开发中会设置默认值为“CURRENT_TIMESTAMP”，update_date设置默认为“CURRENT_TIMESTAMP”。在之前的实践中，习惯将他们的数据类型设置为datetime，然后在业务逻辑中设置修改时间为当前时间，也就是需要sql中显示的设置修改时间。
我们现在的需求是：
当新增记录的时候，mysql自动将系统的当前时间set到创建时间和更新时间这两个字段中。
当更新记录的时候，mysql只update更新时间字段的时间，而不修改创建时间字段对应的值。
解决方法很简单，只需要找到表中对应的创建时间和更新时间的字段，将其修改为下列代码所示。
创建时间字段
`creat_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP
更新时间字段
`update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
核心的DDL语句为 ON UPDATE CURRENT_TIMESTAMP
这样便不需要在代码中对记录设置创建时间和修改时间了。
tomcat7基于Memcached配置session共享踩坑实录
百度的结果可以信，但不可全信。百度结果的特点：别指望用一篇博客内容就解决你所有问题，因为你也不知道
这篇博客是不是抄袭别人的23333333.所以人生苦短，我看官档。
官方文档和issue才是解决问题的硬道理。PS:写博客要按照基本法啊，实践才是检验真理的唯一标准。
那么，就直入主题了，本文就对tomcat7整合memcached会话共享做一次总结。
