Transaction

背景介绍饿了么监控系统EMonitor：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近PB，每日写入指标数据量百T，每日指标查询量几千万，配置图表个数上万，看板个数上千。 CAT：是基于Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务 本文通过对比分析下2者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段 CAT做的事情（开源版）首先要强调的是这里我们只能拿到github上开源版CAT的最新版3.0.0，所以是基于此进行对比 接下来说说CAT做了哪些事情？ 1 抽象出监控模型抽象出Transaction、Event、Heartbeat、Metric 4种监控模型。 Transaction：用来记录一段代码的执行时间和次数Event：用来记录一件事发生的次数Heartbeat：表示程序内定期产生的统计信息, 如CPU利用率Metric：用于记录业务指标，可以记录次数和总和针对Transaction和Event都固定了2个维度，type和name，并且针对type和name进行分钟级聚合成报表并展示曲线。 2 采样链路针对上述Transaction、Event的type和name分别有对应的分钟级的采样链路 3 自定义的Metric打点目前支持Counter和Timer类型的打点，支持tag，单机内单个Metric的tag组合数限制1000。 并且有简单的监控看板，如下图所示： 4 与其他组件集成比如和Mybatis集成，在客户端开启相关的sql执行统计，并将该统计划分到Transaction统计看板中的type=SQL的一栏下 5 告警可以针对上述的Transaction、Event等做一些简单的阈值告警 饿了么EMonitor和CAT的对比饿了么EMonitor借鉴了CAT的相关思想，同时又进行了改进。 1 引入Transaction、Event的概念针对Transaction和Event都固定了2个维度，type和name，不同地方在于聚合用户发过来的数据 CAT的架构图如下所示： CAT的消费机需要做如下2件事情： 对Transaction、Event等消息模型按照type和name进行当前小时的聚合，历史小时的聚合数据写入到mysql中将链路数据写入到本地文件或者远程HDFS上EMonitor的架构图如下所示： EMonitor分2路对数据进行隔离处理： Real-Time Streaming Compute：对用户发过来的链路中的Transaction、Event等监控模型转变成指标数据并进行10s的预聚合，同时也对用户发过来的Metric数据进行10s预聚合。最后将10s预聚合的数据写入到LinDB时序数据库（已开源，有兴趣的可以关注star下）中，以及kafka中，让告警模块watchdog去消费kafka做实时告警Real-Time Data Writer：对用户发过来的链路数据构建链路索引、向HDFS和HBase写入索引和链路数据，同时会构建应用之间的依赖关系，将依赖关系写入到Neo4j中所以EMonitor和CAT的一个很大不同点就在于对指标的处理上，EMonitor交给专业的时序数据库来做，而CAT自己做聚合就显得功能非常受限，如下所示： CAT只能整小时的查看type和name数据，不能跨小时，即不能查看任意2个时间之间的报表数据，EMonitor没有此限制CAT没法查看所有type汇总后的响应时间和QPS，EMonitor可以灵活的自由组合type和name进行聚合CAT的type和name报表是分钟级的，EMonitor是10s级别的CAT的type和name没能和历史报表曲线直接对比，EMonitor可以对比历史报表曲线，更容易发现问题CAT的type和name列表首页展示了一堆数字，无法立即获取一些直观信息，比如给出了响应时间TP99 100ms这个到底是好还是坏，EMonitor有当前曲线和历史曲线，相对来说可以直接判断到底ok不okCAT的TP99、TP999基于单机内某个小时内的报表是准确的，除此之外多机或者多个小时的聚合TP99、TP999是用加权平均来计算的，准确性有待提高但是CAT也有自己的优势： CAT含有TP999、TP9999线(但是准确性还有些问题)，EMonitor只能细到TP99CAT的type和name可以按照机器维度进行过滤，EMonitor没有做到这么细粒度2 采样链路目前CAT和EMonitor都可以通过type和name来过滤采样链路，不同点在于 CAT的采样链路是分钟级别的，EMonitor是10s级别的针对某一个type和name，CAT目前无法轻松找想要的链路，EMonitor可以轻松的找到某个时刻或者说某段时间内响应时间想要的链路（目前已经申请专利）EMonitor的链路如下所示： 这张图是某个10s时刻、某个type和name过滤条件下的采样链路第一行是这10s内的采样链路，按照响应时间进行了排序可以随意点击某个响应时间来查看对应的链路详情3 自定义的Metric打点EMonitor支持Counter、Timer、Histogram、Payload、Gauge等等多种形式的打点方式，并且支持tag Counter：计数累加类型Timer：可以记录一段代码的耗时，包含执行次数、耗时最大值、最小值、平均值Histogram：包含Timer的所有东西，同时支持计算TP99线，以及其他任意TP线(从0到100)Payload：可以记录一个数据包的大小，包含数据包个数、包的最大值、最小值、平均值Gauge：测量值，一般用于衡量队列大小、连接数、CPU、内存等等也就是任意Metric打点都可以流经EMonitor进行处理了并输送到LinDB时序数据库中。至此，EMonitor就可以将任何监控指标统一在一起了，比如机器监控都可以通过EMonitor来保存了，这为一站式监控系统奠定了基础 自定义Metric看板CAT只有一个简易的Metric看板EMonitor针对Metric开发了一套可以媲美Grafana的指标看板，相比Grafana的优势： 有一套类似SQL的非常简单的配置指标的方式跟公司人员组织架构集成，更加优雅的权限控制，不同的部门可以建属于自己的看板指标和看板的收藏，当源指标或看板改动后，无需收藏人员再改动alpha、beta、prod不同环境之间的一键同步指标和看板，无需配置多次PC端和移动端的同步查看指标和看板类SQL的配置查询指标方式如下所示： 可以配置图表的展现形式可以配置要查询的字段以及字段之间的加减乘除等丰富的表达式可以配置多个任意tag的过滤条件可以配置group by以及order by看板整体如下所示： 移动端显示如下： 4 与其他组件集成 目前EMonitor已经打通了IaaS层、PaaS层、应用层的所有链路和指标的监控，再也不用在多个监控系统中切换来切换去了，如下所示 1 IaaS层物理机、机房网络交换机等的监控指标2 PaaS层中间件服务端的监控指标3 应用层SOA、Exception、JVM、MQ等客户端的相关指标4 应用层自定义的监控指标以打通饿了么分库分表中间件DAL为例： ...

为什么需要事务管理器如果没有事务管理器的话，我们的程序可能是这样： Connection connection = acquireConnection();try{ int updated = connection.prepareStatement().executeUpdate(); connection.commit();}catch (Exception e){ rollback(connection);}finally { releaseConnection(connection);}也有可能是这样"优雅的事务"： execute(new TxCallback() { @Override public Object doInTx(Connection var1) { //do something... return null; }});public void execute(TxCallback txCallback){ Connection connection = acquireConnection(); try{ txCallback.doInTx(connection); connection.commit(); }catch (Exception e){ rollback(connection); }finally { releaseConnection(connection); }}# lambda版execute(connection -> { //do something... return null;});但是以上两种方式，针对一些复杂的场景是很不方便的。在实际的业务场景中，往往有比较复杂的业务逻辑，代码冗长，逻辑关联复杂，如果一个大操作中有全是这种代码的话我想开发人员可能会疯把。更不用提定制化的隔离级别，以及嵌套/独立事务的处理了。 Spring 事务管理器简介Spring作为Java最强框架，事务管理也是其核心功能之一。Spring为事务管理提供了统一的抽象，有以下优点： 跨不同事务API（例如Java事务API（JTA），JDBC，Hibernate，Java持久性API（JPA）和Java数据对象（JDO））的一致编程模型。支持声明式事务管理（注解形式）与JTA之类的复杂事务API相比， 用于程序化事务管理的API更简单和Spring的Data层抽象集成方便（比如Spring - Hibernate/Jdbc/Mybatis/Jpa...）使用方式事务，自然是控制业务的，在一个业务流程内，往往希望保证原子性，要么全成功要么全失败。 所以事务一般是加载@Service层，一个Service内调用了多个操作数据库的操作（比如Dao），在Service结束后事务自动提交，如有异常抛出则事务回滚。 这也是Spring事务管理的基本使用原则。 下面贴出具体的使用代码： 注解在被Spring管理的类头上增加@Transactional注解，即可对该类下的所有方法开启事务管理。事务开启后，方法内的操作无需手动开启/提交/回滚事务，一切交给Spring管理即可。 @Service@Transactionalpublic class TxTestService{ @Autowired private OrderRepo orderRepo; public void submit(Order order){ orderRepo.save(order); }}也可以只在方法上配置，方法配置的优先级是大于类的 ...