Druid

最近几周，发生过多起因为事务问题引起的服务报错。现象为数据库连接池连接占满，数据库连接长时间等待，最终导致请求线程hang住，服务大面积报错。这个时候，服务资源、数据库资源大量空闲，但就是进行不下去，影响是比较恶劣的。 谁来背锅？当然是架构师。因为这次所有的服务都活着，没运维什么事。 面试时，大家可能都会碰到关于事务相关的问题，升级版的可能是分布式事务的问题。在互联网行业中，一句马马虎虎的补偿事务就能蒙混过关，毕竟都是些短小精悍的接口。 但在很多企业级应用中，这行不通。我们必须直面惨淡的现实。 为什么要用长事务? 在许多业务非常复杂的后台系统，经常频繁操作DB，为了保证数据的一致性，能够在出错时回滚数据，通常会使用事务。 就拿最简单的单机数据库事务来说。 在事务操作期间，如果持续时间过长，只有等事务结束之后，DB连接才会释放，此类长时间占用DB连接的事务操作，称为长事务。一旦外部有大量请求，并发调用此操作，那么将会有大量的DB连接被持有而没有被释放掉，直到连接池爆满。 这个时候，如果有其他请求到来，那十有八九是以失败告终。 也就是说，连接资源被少数长事务操作占用。在这种情况下，即使是最简单接口查询，都不能够正常进行。 几粒老鼠屎，坏了一锅粥。 一些魔幻的反应 当你去排查这种问题的时候，可能会陷入僵局。jstack显示，多数请求其实是阻塞在tomcat的线程池上

Storm是最流行的实时流计算框架之一，它提供了可容错分布式计算所要求的基本原语和保障机制，可满足大容量关键业务应用的需求。Storm不仅是- -种集成技术，也是一种数据流 和控制机制，已经成为很多大公司大数据处理平台的核心部分。 获取方法 本书特点 本书主要讲述Storm相关的Java开发，但其中的设计模式同样适用于其他编程语言。书中的小窍门、技术和实现方法对架构师、开发人员和运维人员都具有参考价值。Hadoop爱好者会发现，这是一本很好的Storm入门书籍，书中举例说明这两种系统如何优势互补，提供了将批处理运算迁移到实时分析的一种高效途径。本书提供了Storm应用于多个问题和行业的具体示例，这些例子应该能够在其他领域中举一反三， 解决在有限时间内处理大量数据的问题。同时，解决方案设计师、商业分析师也能从本书介绍的高层系统架构和技术中获益。 书本目录 部分内容截图 配置Storm集群 实时趋势分析 整合Druid进行金融分析 在Hadoop上部署Storm进行广告分析 来源： oschina 链接： https://my.oschina.net/u/4335287/blog/3229353

前言 只有光头才能变强。 文本已收录至我的GitHub精选文章，欢迎Star ： https://github.com/ZhongFuCheng3y/3y 在上周总结了一篇「工作中常用到的Java集合类」，反响还不错。这周来写写Java另一个重要的知识点：「 多线程 」 多线程大家在初学的时候，对这个知识点应该有不少的疑惑的。我认为主要原因有两个： 多线程在初学的时候不太好学，并且一般写项目的时候也很少用得上（至少在初学阶段时写的项目基本不需要自己创建线程）。 多线程的知识点在面试经常考，多线程所涉及的知识点非常多，难度也不低。 这就会给人带来一种感觉「 这破玩意涉及的东西是真的广，平时也不怎么用，怎么面试就偏偏爱问这个鬼东西 」 不多BB，我要开始了。 为什么使用多线程？ 首先，我们要明确的是「为什么要使用多线程」，可能有人会认为「 使用多线程就是为了加快程序运行的速度啊 」。如果你是这样回答了，那面试官可能会问你「那多线程是怎么加快程序运行速度的？」 于我的理解：使用多线程最主要的原因是 提高系统的资源利用率 。 现在CPU基本都是多核的，如果你只用单线程，那就是只用到了一个核心，其他的核心就相当于空闲在那里了。 厕所的坑位有5个，如果只用一个坑位，那不是很亏？比如现在我有5个人要上厕所。 在单线程的时候：进去一个人解决要10分钟，然后后面的人都得等一个坑位

六、SpringBoot与数据访问 6.1、JDBC 6.1.1 依赖与配置 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jdbc</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> spring: datasource: username: root password: 123456 url: jdbc:mysql://192.169.0.1:3306/jdbc 6.1.2、 效果 默认是用com.zaxxer.hikari.HikariDataSource作为数据源； 数据源的相关配置在DataSourceProperties里面； 6.1.3、自动配置原理 org.springframework.boot.autoconfigure.jdbc： 1、参考DataSourceConfiguration，根据配置创建数据源，默认使用HikariDataSourcet连接池;可以使用 spring

本文源码： GitHub·点这里 || GitEE·点这里 一、多数据源应用 1、基础描述 在相对复杂的应用服务中，配置多个数据源是常见现象，例如常见的：配置主从数据库用来写数据，再配置一个从库读数据，这种读写分离模式可以缓解数据库压力，提高系统的并发能力和稳定性，执行效率。 2、核心API 在处理这种常见问题，要学会查询服务基础框架的API，说直白点就是查询Spring框架的API（工作几年，还没用过Spring之外的框架搭建环境），这种常用的业务模式，基本上Spring都提供了API支持。 核心API：AbstractRoutingDataSource 底层维护Map容器，用来保存数据源集合，提供一个抽象方法，实现自定义的路由策略。 @Nullable private Map<Object, DataSource> resolvedDataSources; @Nullable protected abstract Object determineCurrentLookupKey(); 补刀一句 ：为何框架的原理很难通过一篇文章看明白？因为使用的不多，基本意识没有形成，熟悉框架原理的基本要求：对框架的各种功能都熟悉，经常使用，自然而然的就明白了，盐大晒的久，咸鱼才够味。 二、数据源路由 1、数据源管理 配置两个数据源 spring: datasource: type: com

spring boot jap+mybatis druid 多数据源配置 , 其实并不难的， 关键不能乱来，否则 配置 好了之后，可能 druid 数据源 的连接也可能爆某些莫名诡异的错误，比如连接 超时啊，连接不可用啊等等。 多数据源配置不好的话，很容易 出问题和BUG。 会把人搞疯了。 The last packet successfully received from the server was 1,843,135 milliseconds ago. The last packet sent successfully to the server was 18,904 milliseconds ago. 2020-03-31 14:04:50 [http-nio-9180-exec-2] ERROR c.n.m.handler.GlobalExceptionHandler - 请求：http://localhost:9180/auth/report/employee/performance?ifContainSub=%20true&brandId=%200&orgId=%201&page=%201&pageSize=%2010&c_token=ab2ebb088e874167ba1f3e3cdc2392f5&c_user_id=28&c_session

依赖加入 <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.1.18</version> </dependency> 　　 YML spring: datasource: driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/student?useUnicode=true&characterEncoding=utf-8 username: root password: 12345678 # druid 配置 dbType: mysql # 指定数据库类型 mysql initialSize: 5 # 启动初始化连接数量 minIdle: 5 # 最小空闲连接 maxActive: 20 # 最大连接数量（包含使用中的和空闲的） maxWait: 60000 # 最大连接等待时间 ，超出时间报错 timeBetweenEvictionRunsMillis: 60000 # 设置执行一次连接回收器的时间 minEvictableIdleTimeMillis: 300000 # 设置时间： 该时间内没有任何操作的空闲连接会被回收 validationQuery: select

Druid简介 Druid是阿里开源的数据库连接池，作为后起之秀，性能比dbcp、c3p0更高，使用也越来越广泛。 druid的优点 高性能。性能比dbcp、c3p0高很多。 只要是jdbc支持的数据库，druid都支持，对数据库的支持性好。并且Druid针对oracle、mysql做了特别优化。 提供监控功能。可以监控sql语句的执行时间、ResultSet持有时间、返回行数、更新行数、错误次数、错误堆栈等信息，来了解连接池、sql语句的工作情况，方便统计、分析SQL的执行性能 Druid的使用 添加druid的依赖、数据库驱动 <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.1.8</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.19</version> </dependency> 纯代码方式 　　　　//数据源配置 DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl("jdbc

主流Java数据库连接池比较及前瞻 https://www.jianshu.com/p/b9b98ac3e010 一、主流数据库连接池 C3p0: 实现数据源和JNDI绑定，支持JDBC3规范和JDBC2的标准扩展。Hibernate、Spring使用。单线程，性能较差，适用于小型系统，代码600KB左右。 DBCP (Database Connection Pool):Apache的， Jakarta commons-pool对象池机制，Tomcat使用。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar，预先将数据库连接放内存中，建立数据库连接时，直接到连接池中申请，用完放回。单线程，并发量低，性能不好，适用于小型系统。 Tomcat Jdbc Pool：Tomcat在7.0以前都是使用，单线程，保证线程安全会锁整个连接池，性能差，超过60个类复杂。Tomcat从7.0开始叫做Tomcat jdbc pool，基于Tomcat JULI，使用Tomcat日志框架，完全兼容dbcp，异步方式获取连接，支持高并发应用环境，核心文件8个，支持JMX，支持XA Connection。 BoneCP：高效、免费。设计提高性能，速度最快，高度可扩展：集成Hibernate和DataNucleus中

3 月，跳不动了？>>> 刚用谷歌解决了一个问题，这个问题如果用百度是没办法解决的。 问题：提交DRUID索引报错 报错信息为： { "error": "Cannot construct instance of `org.apache.druid.indexing.common.task.batch.parallel.ParallelIndexSupervisorTask`, problem: `java.lang.NullPointerException`\n at [Source: (org.eclipse.jetty.server.HttpInputOverHTTP); line: 69, column: 1]" } 最快的解决办法是利用搜索引擎来搜索关键词：Cannot construct instance of `org.apache.druid.indexing.common.task.batch.parallel.ParallelIndexSupervisorTask` 通过百度搜索结果为： 通过谷歌搜索结果为： 百度搜索结果就是垃圾，谷歌搜索结果的第一条就是解决方案。 如何从码农成长为CTO？其实很简单，能读懂英文，会用谷歌，基本上就可以了。 来源： oschina 链接： https://my.oschina.net/apdplat/blog/3209466