愤怒的菜鸟

原创 canal解析mysql binlog报错：Did not write as much data as expected.

canal版本：canal.deployer-1.1.3Mysql版本：5.6.41-log错误：2019-06-13 10:16:08.825 [destination = bigdata_collect , address = /192.168.43.6:3306 , EventParser] WARN c.a.o.c.p.inbound.mysql.rds.RdsBinlogE...

原创 对“经历400多天打磨的HSF“感受

用了400天重构的HFS2.2，用他的架构图对比下dubbo 架构图，不用多说，你懂得！dubbo架构图：

原创 Kafka+Influxdb+Grafana实现灵活集群服务监控

最近完成了交易服务监控，采用如下方案：Kafka 消息总线，所有服务监控数据采集后都发到这里。Influxdb 时序数据库，特别合适存储日志类数据，不需要做表设计，可支持索引，类SQL查询，增强型数据统计功能。Grafana 强大的可视化数据展示界面。

原创 jetty9 websocket发送消息死锁，引发内存溢出

最近在做一个金融项目，做了一个网关，用来对接各种终端，长连接不断推送期货行情。（jetty9 websocket）长连接的方案采用websocket，上线前，做单个终端的压力测试，传输数百万数据，跑了10多小时，一切正常。但是上线后，发现时间不规则的内存溢出，有时可能4天就死了，有时半天就死了，甚是郁闷。dump出内存堆，使用mat分析，很容易看到byte[]非常大，占60

原创 java与python性能对比，差一个数量级

以下用金融里面的常见参数，计算移动平均值，分别用python和java编写运行，结果对比发现，相差一个数量级。python版from __future__ import divisionimport timeimport random# 生成测试用的数据data = []data_length = 100000 # 总数据量ma_length = 500

原创 使用groovy脚本自动清理过多Elasticsearch索引

之前搭建了一套ELK方案分布日志采集系统，一直运行比较稳定，每日采集日志量600万+，存放es索引的磁盘只有150G，一般1个月左右就满了，所以必须定期清理一下旧索引，以免爆了引起连锁反应，导致整个应用链都挂了。手工清晰比较麻烦，花了点时间，使用groovy写了个脚本，配合linux cron定时每天执行，效果理想。@Grab('com.squareup.okhttp:okhttp

原创 四步循序渐进，微服务落地方案

四步循序渐进，微服务落地方案

原创 并发测试Twitter snowflake id，顺带测试了下几种list set的性能和线程安全性

final int threadC = 300; final int loopC = 1000; //final Set idCounter = Sets.newConcurrentHashSet(); final List idCounter = new ArrayList<>(threadC*loopC); final IdWorker idWorker = new Id

原创 巧妙使用数组，内部匿名类改变外部类final对象值

final boolean confirmFlag[] = new boolean[]{false}; SwingUtilities.invokeLater(new Runnable() { @Override public void run() { Object[] options = { "确定", "取消" }; int

转载 了解 CMS 垃圾回收日志

在CMS GC 时,使用参数-XX:+PrintGCDetails 和 -XX:+PrintGCTimeStamps 会输出很多日志信息，了解这些信息可以帮我们更好的调整参数，以获得更高的性能。我们来看下在JDK1.4.2_10 中CMS GC日志示例：39.910: [GC 39.910: [ParNew: 261760K->0K(261952K), 0.2314667 secs] 26

原创 微服务分布式事务落地方案

网上很多关于微服务的文章都是虚无缥缈的，长编大论玩文字概念。本文我想跟大家探讨一下微服的具体落地方案。在架构设计领域，有一个跟微服务很相似的概念叫“微内核”。微内核实质就是强化面向接口编程，内核只负责逻辑调用流程，具体实现方法由外部插件配置提供。比较典型的具体实现方式就是JDK SPI机制。（dubbo就是采用了微内核思想开发的）技术发展都是类通的，就是一个不断抽象的过程，微服务其实就

原创 纪念一下曾经的监控系统：ELK+HightChart

前端采用logstash采集各分布系统日志，数据发往redis队列，旁路出一条数据链路到监控系统做数据实时计算汇总统计，最后形成图表。另一路到es保存，作为全文检索日志分析使用。

原创 设计一个实用、可自动化测试的智能购物车

最近在对公司的团购业务订单流程进行重构，从php转移到java上，重构的重点在购物车上。目标：设计一个解耦、实用，可自动化测试的智能购物车。上图不说话：

原创 Spring启动，constructor,@PostConstruct,afterPropertiesSet,onApplicationEvent执行顺序

package com.xx;import javax.annotation.PostConstruct;import javax.annotation.Resource;import org.springframework.beans.factory.InitializingBean;import org.springframework.context.ApplicationList

转载 日消息量突破50亿，谈小米的高可用推送系统设计

该文章思路清晰，行云流水，徐然说的是推送系统，但是思想是共通的，值得大家一看。小米推送是目前国内领先的推送服务提供商，主要为开发者提供快捷、准确、稳定的推送服务。目前日活跃设备突破3亿，日消息量突破50亿。本文将会介绍小米推送在提高系统可用性方面的一些经验和教训。推送系统的高可用性以及如何提高可用性缓冲机制与服务解耦无状态服务以及多机房部署

原创 kafka+观察者模式，实现高性能事件总线

一个事件总线的实现，主要包含三个较色：1、消息发布  2、消息队列  3、消息派送消息队列可以有多种选择，redis,kafka,rocketMQ等，甚至是jdk bockQueue。但作为一个工业级的设计，我们需要考虑几点：1、高性能  2、高可用  3、平滑扩容  4、架构对开发者透明1、2、3取决于你用什么消息队列，4 取决于你采用哪种设计模式进行解耦经过

原创 Spring IOC容器启动核心

ClassPathResource resource = new ClassPathResource("services.xml"); DefaultListableBeanFactory factory = new DefaultListableBeanFactory(); XmlBeanDefinitionReader reader = new XmlBeanDefi

转载 java 线程的几种状态

java thread的运行周期中, 有几种状态, 在 java.lang.Thread.State 中有详细定义和说明:NEW 状态是指线程刚创建, 尚未启动RUNNABLE 状态是线程正在正常运行中, 当然可能会有某种耗时计算/IO等待的操作/CPU时间片切换等, 这个状态下发生的等待一般是其他系统资源, 而不是锁, Sleep等BLOCKED  这个状态下, 是在多个线程

转载 spring中bean的生命周期

1. 容器寻找Bean的定义信息并将其实例化2. 使用依赖注入，spring按照Bean定义信息配置Bean的所有属性3. 如果Bean实现了BeanNameAware接口，工厂调用Bean的SetBeanName()方法传递Bean的ID4. 如果Bean实现了BeanFactoryAware接口，工厂调用setBeanFactory()方法传入工厂自身5. 如果

原创 嵌套事务的一次实践

最近在一个项目中，需要实现自动对账功能，收银机会定时对比本地和远程的订单，远程发现缺少的，会自动补全。所谓补全，就是批量插入缺失的订单。基于这个场景，就存在一个细节的问题，因为插入订单涉及两个表，如果某些情况下，一个表插入失败，订单插入事务需要回滚。但是不能回滚之前插入的订单数据，显然这里就设计子事务问题。现在这个对账功能，是A->B这个方式，B就是订单插入方法。A使用的是通常的R

原创 告诉你一个dubbo token使用秘技

最近在做公司一个互联网收银机项目里面，需要调用一些远程服务接口，综合性能、安全和便捷考虑，决定使用rpc方式调用。rpc框架，采用dubbo。我们知道，一般使用dubbo rpc都是在内网环境部署，然后采用zookeeper作为配置服务器进行集群。基于这次作为外网使用，不想过多地暴露内网服务，也没必要去维护一个远程的zookeeper连接，所以我决定采取消费端直连服务端模式。

原创 发布：dubboPlus - 支持thrift原生协议(dubbo扩展)

基于dubbo2.5.3扩展高性能的、支持容错的、协议无关的RPC框架增加了对thrift原生协议支持，从而实现了跨语言调用（C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml）        项目源码：https://gith

转载 Java GC 日志分析秒懂!

原创 对dubbo进行重构，支持thrift原生协议直接调用

整体思路：不入侵，不改变dubbo原来的任何特性，新增对thrift原生协议支持，原生协议的调用，同样可以进行原来的监控统计。唯一丢失的特性，就是没有了软路由。因为原生协议不是使用dubbo客户端调用。 网上有一种改造的方法，对整条调用链都改了，包括：protocol,exchange,transport,request,response都改了，使用thrift原生server解释执行

原创 dubbo三种协议性能对比

原创 dubbo dubbo-thrift thrift三种协议直观对比

最近在研究学习dubbo源码，下面对比一下dubbo dubbo-thrift thrift三种协议序列化后报文体积：远程调用一个简单方法：Hello.hello("哈哈哈"); dubbo:{ -38, -69, -62, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -48, 5, 50, 46, 48, 46, 48, 48,

转载 性能分析之-- JAVA Thread Dump 分析综述

最近在做性能测试，需要对线程堆栈进行分析，在网上收集了一些资料，学习完后，将相关知识整理在一起，输出文章如下。 一、Thread Dump介绍1.1什么是Thread Dump？Thread Dump是非常有用的诊断Java应用问题的工具。每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力，虽然各个 Java虚拟机打印的thread dump略有不同

原创 Hive JDBC运行连接注意事项

通过jdbc方式连接hive，能让你非常方便、简单地去使用hadoop挖掘数据，门槛大大降低。其实连接方式很简单，但是第一次使用，总会有些莫名奇妙的错误，下面给出一些注意事项，希望对初学者有帮助。首先我的环境：hadoop2.4.0+hive0.14.0。 所需jar包：                                    

原创 ubuntu-14.04.1+hadoop2.4完全分布式搭建要点

最近帮公司搭建hadoop集群，现在总结一下相关要点：1、没有搭建过hadoop的，建议先搭建一个伪集群体验一下2、建议最少集群机器配置：5台。 1台NameNode  1台 ResourceManager 3台DataNode3、完全分布集群搭建的重点、难点就是无密SSH登录，很多人会卡在这里。重点： 各个服务器创建同一个账号，同一个用户组 ssh

原创 一次关于Netty+Gson造成内存泄露 Memory Analysis分析

http://just2do.iteye.com/admin/blogs/2181293  之前写过一篇使用java自带工具去分析内存泄露问题，今天使用 Memory Analysis重做一次，看看高级工具是否能一针见血地更方便地发现问题。 第一步： jmap -dump:format b,file=abc.hprof dump出内存日志  第二部： 使用Mem

原创 同步转异步+RPC的一个POS行业应用-业务模型介绍

最近在做一个挺有意思的POS消费项目，工作量不太大，但涉及的技术运用还挺有意思的。可能有人奇怪，POS项目怎么用到JAVA语言了，先来简单介绍下这个项目背景： 改造前：收银机下单，POS机下单并刷卡支付改造后：收银机跟POS连线，收银台直接下单并触发POS刷卡支付动作 这里就涉及一个关键问题，POS机只能单线程工作，就是一个时刻只能干一件事情，比如打印，刷卡，跟卡主机通讯，

原创 同步转异步+RPC的一个POS行业应用-关键技术实现

简单回顾下业务模型：收银台POS代理服务器POS机，三者之间进行通讯，POS代理作为一个报文转换和同步转异步角色。下面介绍下几个关键技术实现:1、报文这里的报文，指的是POS代理服务器跟POS通讯之间约定的报文。根据POS交易类型，支付、刷卡、打印等，约定每个交易报文包含什么字段信息和长度，其中一个比较特别字段是UUID，这个字段是每个报文的关键字段，具有唯一性，每个报

原创 一次关于Netty+Gson造成内存泄露的分析排查

最近做了一个内部系统之间的数据同步服务器，client端通过socket发送经过压缩的json数据到server端，server完成数据解码和保存。server架构：netty+Gson解码 在做压力测试的时候，竟然发现server内存泄露。分析内存泄露的时候，其实我们可以从简单方法入手，因为jdk1.6后自身就带有不错的内存分析工具，而且我认为使用好这些工具基本足够高，因为如果你对这些工

原创 转移博客来这里了

Iteye没落了。。。。