InfluxDB 与 Elasticsearch 的时间序列数据和指标基准 在过去的几周里,我们开始比较 InfluxDB 和 Elasticsearch 在时间序列工作负载方面的性能和功能,特别关注数据摄取率、磁盘数据压缩和查询性能。然而,对于那些寻找有效起点的技术将提供更好的“开箱即用”时间序列数据摄取、压缩和查询性能的人来说,InfluxDB 在所有这些维度上都是明显的赢家,特别是当数据集变得更大,系统运行的时间更长。我们的首要目标是创建一致的、最新的比较,反映 InfluxDB 和 Elasticsearch 的最新发展以及后来对其他数据库和时间序列解决方案的报道。
Nacos配置中心-介绍与配置 当微服务部署的实例越来越多,达到数十、数百时,逐个修改微服务配置就会让人抓狂,而且很容易出错。我们需要一种统一配置管理方案,可以集中管理所有实例的配置。Nacos一方面可以将配置集中管理,另一方可以在配置变更时,及时通知微服务,实现配置的热更新。微服务要拉取nacos中管理的配置,并且与本地的application.yml配置合并,才能完成项目启动。但如果尚未读取application.yml,又如何得知nacos地址呢?
ElasticSearch ES从入门到精通 Elasticsearch是位于 Elastic Stack 核心的分布式搜索和分析引擎。Elasticsearch 是索引、搜索和分析魔法发生的地方。lasticsearch 为所有类型的数据提供近乎实时的搜索和分析。无论您拥有结构化或非结构化文本、数字数据还是地理空间数据,Elasticsearch 都能以支持快速搜索的方式高效地存储和索引它。您可以超越简单的数据检索和聚合信息来发现数据中的趋势和模式。随着您的数据和查询量的增长,Elasticsearch 的分布式特性使您的部署能够随之无缝增长。
pinpoint链路跟踪运用及日志logback配置 pinpoint是一款 APM监控工具(Application Performance Management/应用性能管理)基于java编写用于 大规模分布式系统 的监控,是 分析 大规模分布式系统 的平台基于google Dapper开发,目标就是为n(n>=1)层架构开发新的跟踪平台,为n层架构的系统 提供 处理大量跟踪数据 的 解决方案能够对 基于java的 大规模分布式系统和应用 做调用链的跟踪提供了一个web页面 展示 分布式系统的拓扑图 以及 系统这各个组件之间关系。
InetAddress.getLocalHost() 执行非常慢 昨天同事反馈网关的请求非常慢,一个获取的token的接口响应都超过了30s,还好只是测试环境。经过验证,几乎所有接口响应都很慢,很多都响应超时。排查步骤:0. 本地启动项目测试,没有这个问题。而且生产环境也没这个问题,推测是 环境问题,或择资源问题导致。1. 通过arthas的trace命令来查找方法执行链路上的 哪里比较耗时。但通过验证,调用方等待请求响应,花了70s,从arthas的日志来看,只花费了0.01ms。因此推测,耗时是在进入目标方法只之前,都已经卡主了。2. 由于拦截器比较多,就没有去分析哪
windows服务器下java程序健康检测及假死崩溃后自动重启应用、开机自动启动 该篇文章涉及到技术点有:1. java调用本地命令处理方式,2. 通过环境变量配置项目,3. spring动态创建bean,4. maven-ant插件的使用,5. windows定时任务配置,6. actuator的使用。---一个windows上的批处理任务,需要接到mq的消息通知后执行,为了快速实现这里我们通过springboot写了一个jar程序,用于接收mq的消息,并调用bat文件。
Java JVM致命错误日志(hs_err_pid.log)分析 当jvm出现致命错误时,会生成一个错误文件 hs_err_pid.log,其中包括了导致jvm crash的重要信息,可以通过分析该文件定位到导致crash的根源,从而改善以保证系统稳定。当出现crash时,该文件默认会生成到工作目录下,然而可以通过jvm参数指定生成路径(JDK6中引入):1该文件包含如下几类关键信息:日志头文件导致crash的线程信息所有线程信息安全点和锁信息堆信息本地代码缓存编译事件gc相关记录jvm内存映射jvm启动参数服务器信息。
springboot+dubbo项目启动项目时报错 zookeeper not connected 推测由于vpn的方式连接的 zk服务器,很有可能是 3秒内没有得到服务端的正确响应,而导致了异常,然后抛出了异常。项目在公司网络启动时,能正常启动。但通过vpn连接到公司网络时却无法启动报下面的错误。基于上的推测,将该timeout的默认值3000改大一些后,然后就启动成功了。修改dubbo的配置,下面是springboot的项目,修改的方式。下面配置了三个配置的超时时间,可根据情况进行配置。,也就说3秒内需要链接成功,否则就会超时。进一步经过报错的日志,找到对应的源码。从上面的报错信息是可以看出是。
sonar覆盖率、代码覆盖率、分支覆盖率的计算方式 代码质量的覆盖率分为三种,覆盖率、代码覆盖率、分支覆盖率,那每一种的计算方式是怎么样的呢?举例:上面最有疑惑的是覆盖率,不知道怎么算出了来的,后面再说。
nginx线上环境获取不到header头token登录信息 个人比较推荐这种方式。常见的header变量都是遵循这种方式,例如:Content-Type,Content-Length,Accept-Ranges等。但是本次是上线过程中发现的问题,就采用了方案二在nginx里的nginx.conf配置文件中的http部分中添加如下配置:nginx默认request的header的那么中包含_时,会自动忽略掉。
MYSQL数据库外键批量备份(还原)及批量删除外键 在上一篇文章《便捷的批量修改MySQL数据库表及字段的字符集及排序规则》 中进行批量修改表字段的字符集及排序规则时,如果字段有被外键引用,则无法进行修改,会报错,如:这种问题的解决的思路是:上面的操作如果针对小范围的修改,可以手工进行备份和还原,如果存在多个表批量操作的话 手工操作就比较繁琐。下面提供了备份外键和删除外键的SQL。主要是通过 mysql的的和两张表进行实现。注意:在执行删除前,一定要先备份备份SQL
便捷的批量修改MySQL数据库表及字段的字符集及排序规则 当一个数据库中的表中有不同的字符集、排序规则时,sql联表查询的时候就有可能出错。如:Illegal mix of collations (utf8_bin ,IMPLICIT) and (utf8mb4_general_ci,IMPLICIT)。这是由于创建表时指定的排序规则不一致导致的,原因可能是创建表的不是同一拨人,或者是有部分表是程序自动创建的,导致不一致的。存储字符集 是 Mysql 中的一种字符集,只支持最长三个字节的 UTF-8 字符,也就是 Unicode 中的基本多文本平面。要
学习工作流flowable遇到的问题 设置nullCatalogMeansCurrent=true,表示mysql默认当前数据库操作,在mysql-connector-java 5.xxx该参数默认为true,在6.xxx以上默认为false,因此需要设置。因为mysql使用schema标识库名而不是catalog,因此mysql会扫描所有的库来找表,如果其他库中有相同名称的表,activiti就以为找到了,本质上这个表在当前数据库中并不存在。
H5与小程序该怎么选,各自的优缺点 因此,与公众号不同,小程序没有关注和推送营销消息等营销功能,(虽然小程序也可以在特定条件下发送服务消息,但官方明确指出不可用于营销目的),主要侧重满足功能性的需求。如果开发者拥有多个移动应用、网站应用、和公众帐号(包括小程序),可通过 UnionID 来区分用户的唯一性,因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号(包括小程序),用户的 UnionID 是唯一的。所以说,如果你的开发公司同时具备H5和小程序的开发经验,同等的功能量级,小程序的开发成本会稍微低一些,不过这个差别不会太大。
git命令判断当前分支是否与master合并 有的时候在编写批处理脚本时,需要判断git的当前分支是否与目标分支合并,则可以通过下面的脚本进行判断。是对应的目标分支,表示当前分支是否已经合并到了master分支。是获取当前分支最后一次提交的commitId,如。用于存储 是否合并的结果,
双重检查锁中的指令重排问题---Java单例模式实现 使用synchronized之后,可以保证线程安全,但是synchronized将全部代码块锁住,这样会导致较大的性能开销,因此,人们想出了一个“聪明”的技巧:双重检查锁DCL(double checked locking)的机制实现单例。指令重排序是指编译器或处理器为了优化性能而采取的一种手段,在不存在数据依赖性情况下(如写后读,读后写,写后写),调整代码执行顺序。这是一个懒汉式的单例实现,众所周知,因为没有相应的锁机制,这个程序是线程不安全的,实现安全的最快捷的方式是添加 synchronized。