- 博客(146)
- 资源 (1)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 JVM系统优化实践（23）：GC生产环境案例（六）
在互联网大厂中，对每天亿级流量的日志进行清洗、整理是非常常见的工作。在某个系统中，需要对用户的访问日志做脱敏处理，也就是清洗掉姓名、身份证号、手机号等个人隐私信息后在保存到数据库中或者交付给其他应用使用。
2023-07-26 19:55:37
438
原创 JVM系统优化实践（22）：GC生产环境案例（五）
除了Tomcat、Jetty，另一个常见的可能出现OOM的地方就是微服务架构下的一次RPC调用过程中。笔者曾经经历过的一次OOM就是基于Thrift框架封装出来的一个RPC框架导致的宕机。
2023-07-24 20:02:44
803
1
原创 JVM系统优化实践（21）：GC生产环境案例（四）
前面说了一般应用的OOM情况，但是OOM不知发生在应用层，有时候专门负责运行Java的Tomcat也会偶尔罢工一下，抛出OOM异常。因为Tomcat本身也是一个JVM进程。
2023-07-21 19:45:26
310
原创 JVM系统优化实践（20）：GC生产环境案例（三）
某新手开发工程师接到了一个保存Elasticsearch日志的任务，以供后续分析之用。但写代码的时候，误将保存日志的代码段弄成了无限循环，程序启动后，没用多久就崩溃了。
2023-07-19 21:08:57
1307
原创 JVM系统优化实践（19）：GC生产环境案例（二）
接昨天的问题继续来说，在高并发场景中，对象过多容易导致OOM。由于高并发导致Young GC存活对象过多，因此会有太多对象进入老年代，导致老年代也被填满，频繁触发Full GC，而老年代空间也很快被塞满。可以用图来表示。
2023-07-17 20:25:03
381
原创 JVM系统优化实践（18）：GC生产环境案例（一）
生产环境中，最常见的一种案例就是OOM，也叫「内存溢出」，它表示JVM已经无法支撑业务系统的运行。而很多工程师都没有类似处理线上系统故障的经验，尤其是这种突发的故障。
2023-07-15 07:30:00
295
原创 JVM系统优化实践（17）：线上GC案例（二）
GC的概念并不难明白，而且它的原理也不复杂，但是很难用好。6、老年代Full GC触发规则:老年代已用空间大于老年代空间阈值、Young GC前：老年代可用空间小于历次Young GC后进入老年代的对象的平均大小、Young GC后：老年代空间放不下Young GC后存活对象；用jstat观察JVM的运行过程，尤其要注意：Eden区的增长速率、Young GC频率、Young GC耗时、Young GC后多少对象存活、老年代增长速率、Full GC频率、Full GC耗时。欢迎骚扰，不胜荣幸～
2023-04-19 07:30:00
512
1
原创 JVM系统优化实践（16）：线上GC案例（一）
一般新手工程师在部署生产环境时基本不会对JVM进行设置，基本跟上也都是使用JVM的默认设置，这是一个很大的隐患。例如，如果不设置-Xmx或者-Xms的话，可能初始的年轻代和老年代就几百M大小。Full GC一般在正常情况下，都是按天为单位来发生的，比如每天一次，或几天一次Full GC。
2023-04-18 07:30:00
263
原创 JVM系统优化实践（15）：GC可视化工具实践
线上系统的JVM监测要么使用jstat、jmap、jhat等工具查看JVM状态，或者使用监控系统，如Zabbix、Prometheus、Open-FaIcon、Ganglia等。作为一个工具人，怎么能不懂jstat、jmap、jhat呢？
2023-04-10 07:30:00
438
原创 JVM系统优化实践（14）：GC可视化工具
工欲善其事，必先利其器。知道了GC工作原理，学会了看GC日志之后，再来了解一下分析GC的工具。它们分别是jstat、jmap、jhat。
2023-04-07 07:30:00
313
原创 JVM系统优化实践（13）：GC动手实践
上一次留了个小尾巴：怎么以通过代码模拟对象年龄在15岁之后才进入老年代呢？自己试着实现了一下。然后再结合之前了解的其他GC知识，来模拟更多的触发GC的实例。
2023-04-03 07:30:00
209
原创 JVM系统优化实践（12）：GC日志分析
了解了基本的G1垃圾回收机制以后，就可以结合实际日志分析一下它的日志内容了，以后再遇到问题自己也能看懂。
2023-03-27 21:38:29
595
原创 JVM系统优化实践（11）：GC如何搞垮线上系统
看了那么多G1 GC的传说，再来看看一些具体的GC案例以及怎么预防GC把工程师精心设计的系统给搞垮。
2023-03-23 07:30:00
361
原创 JVM系统优化实践（10）：G1混合回收
G1替代了ParNew+CMS这对搭档组合，既能实现年轻代的垃圾回收，也能实现老年代的垃圾回收。现在继续来说说它的混合回收问题。
2023-03-21 07:30:00
342
原创 JVM系统优化实践（9）：G1垃圾回收器
在JDK8及其之前，一直用的都是ParNew+CMS的组合：ParNew负责年轻代的垃圾回收，而由CMS负责老年代的垃圾回收，但会产生Stop the World这个无法避免的问题。
2023-03-08 07:48:19
529
原创 JVM系统优化实践（8）：订单系统的垃圾回收案例
上回说到了年轻代和老年代的两个垃圾回收器：ParNew和CMS，并且将CMS的GC过程也一并介绍了，现在来看个订单系统的案例。
2023-03-06 06:58:11
404
原创 JVM系统优化实践（7）：垃圾回收器与垃圾回收算法
上回说到了年轻代、老年代与数据计算的一个案例。接下来就先讲一讲年轻代和老年代的两个垃圾回收器：ParNew和CMS。
2023-03-04 07:30:00
420
原创 JVM系统优化实践（6）：年轻代、老年代与数据计算
如果当前Survivor区中年龄相同的一批对象总大小 ≥ Survivor总数× 50%，那么这批对象及比它们年龄更大的对象，就都直接进入老年代。但是也有可能在Minor GC之后，发现剩余的存活对象太多，导致其大小总和超过Survivor区域，那么就会把这些对象直接转移到老年代，也不计算所谓的50%。
2023-03-02 07:30:00
243
原创 JVM系统优化实践（5）：什么时候GC以及有哪些GC
既然程序运行会产生大量的废弃物，也就是「垃圾」，那总不能一直堆着不管吧。现在就来粗浅地谈谈Java里面什么时候会触发GC以及有哪些GC。
2023-02-28 07:30:00
665
原创 架构师怎么做管理：接口文档管理
任何一个优秀的互联网系统，都离不开各类研发岗位上工程师们的通力协作，而且这种协作必须是以高效的、低成本的沟通方式进行。软件开发从过去的小作坊到现在几十几百人，到现在成千上万人的同时参与，这里面如果没有一个好的协作工具，是不可能进行下去的。对于工程师来说，开发文档就是这样一个低成本、高效率的沟通工具。但奇怪的是，很多工程师都不愿意写文档，尤其是开发文档（或者说接口文档），因为他们觉得只要有技术就可以了，文档啥的有没有都无所谓。
2023-02-27 18:00:00
376
原创 基于SpringCloud的可靠消息最终一致性06：轮询事务消息
对于同一个事务消息，在正常情况下它要被发送至少两次。这是因为在发送消息之前，TransactionMessageService就已经把消息保存到了数据库中。而在首次消费完消息后，TransactionMessageListener并没有从数据库中删掉，数据库中保存的消息，将被轮询服务AppListenerScheduleExecutor再次发送。
2023-02-27 17:00:00
327
原创 基于SpringCloud的可靠消息最终一致性05：保存并发送事务消息
在有了分布式事务的解决方案、项目的需求、骨架代码和基础代码，做好了所有的准备工作之后，接下来就可以继续深入了解「核心业务」了。
2023-02-27 16:00:00
348
原创 基于SpringCloud的可靠消息最终一致性04：项目基础代码
好的架构其实是慢慢演变出来的，但良好的面向对象特性，一定是设计出来的。从图中可以看出，这里又为每个层次定义一个父类，并继承自BaseObject。例如BaseEntity表示所有实体类的父类，继承自BaseObject；BaseService表示所有服务类的父类，也继承自BaseObject。这样做可以将职责更加细化，可以参照Java中的集合类继承结构。
2023-02-27 15:00:00
260
原创 基于SpringCloud的可靠消息最终一致性03：项目骨架代码（下）
由于项目使用了MySQL、MongoDB、Redis、ActiveMQ、Nacos等中间件，这里就不一一安装了。基本骨架搭建完毕之后，下一步就可以开始充实内容了。
2023-02-26 11:00:00
431
原创 基于SpringCloud的可靠消息最终一致性02：项目骨架代码（上）
之前已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用SpringCloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。
2023-02-26 09:00:00
514
原创 基于SpringCloud的可靠消息最终一致性01：定理、解决方案和框架
很多同学都知道分布式事务很好很强大，而且互联网上也有很多分布式事务的相关理论和解决办法，例如CAP、BASE、2PC、TCC、XA、最大努力通知、柔性事务等等，但这些理论全都缺少完整的实际案例作为参考指引（这里说的「实际案例」，不是指的几段代码，或者一两个类文件，而是指从数据库设计到最后可以部署的完整项目），所以好多人也就不知道该怎么结合实际业务场景来实践它们。
2023-02-26 07:30:00
376
原创 JVM系统优化实践（4）：以支付系统为例
前面说过，JVM会将堆内存划分为年轻代、老年代两个区域。年轻代会将创建和使用完之后马上就要回收的对象放在里面，而老年代则将创建之后需要长期存在的对象放在里面。那么现在再来看一个比较具体的例子。
2023-02-26 07:30:00
355
原创 规则引擎与风控系统05：其他规则引擎
其实更复杂的基于规则的风控系统也都是从简单到复杂慢慢演化出来的。虽然Drools很强大，但它也不是唯一的规则引擎，还有另外两个也同样出色，它们是Groovy和Aviator。
2023-02-25 15:00:00
550
原创 规则引擎与风控系统04：风控系统实例（下）
上一节把风控实例的基础代码都撸了出来。接下来再来把核心服务代码和规则文件写出来。因为有了实体类、Dao，所以接来下就可以写服务类了。之前说过这个实例就是要实现两个目的：1、一分钟内连续访问三次以上，就会被直接封杀；2、黑名单用户登录会记录可疑事件。
2023-02-25 14:00:00
351
原创 规则引擎与风控系统03：风控系统实例（上）
就笔者个人创业经验，对小公司而言，最快最有效的风控手段可能就是「事件监控」和「黑名单」这两种了。原因就是简单好实现，而且实现成本几乎可以忽略不计。至于之前介绍的那些「标准/风控模型」，是在有了团队、技术及资金支持（也就是有钱了，有人了，可以想怎么折腾都行了）的情况下，才能着手实施的。而且「黑名单」也是基本上来源于「事件监控」。
2023-02-25 11:00:00
547
原创 规则引擎与风控系统02：规则引擎
由于运行规则总是会变来变去，而技术同学又不想每次规则变化就改一次代码然后变成地中海。也就是说，必须有一种技术手段，将活动规则和代码进行解耦，不管规则怎么变，代码都不用改。真有可以这么神奇么？——确实有一种这样的「解耦」技术，那就是「规则引擎」。所谓「规则引擎」，根据某百科的解释是：「是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。它接受数据输入，解释业务规则，并根据业务规则做出业务决策」。
2023-02-25 10:00:00
611
原创 规则引擎与风控系统01：新问题，新挑战
有些行为（比如薅羊毛）虽然没有病毒、木马、漏洞等攻击来的直接，但是如果一直被黑灰产（羊毛党、刷单党等）长期吸血，企业生存下来的几率也会很低，而且这些也会严重影响正常用户的体验和利益。基于此，互联网平台借鉴了金融行业中的「风控」（风险控制）机制，主要是对欺诈和作弊行为采取了有针对性的应对策略，而不再像过去那样只知道救火。
2023-02-25 07:30:00
411
原创 用Netty实现物联网07：提升系统性能
之前的业务需求明确了需要区分终端的在线或离线状态。由于在Netty中，客户端与服务端连接时都会启动一个新的线程，在每个线程中都有唯一的ChannelHandlerContext对象，它是当前客户端连接的唯一通道。所以，可以利用这个唯一通道和客户端的IMEI号实现会话管理。
2023-02-24 16:00:00
577
原创 用Netty实现物联网06：自动断开连接与自定义指令
在实际项目的运行中，硬件并不是时时刻刻都在发送数据，而是会按照设定的时间间隔，有规律地传输。或者有些硬件终端因为故障、电源耗尽而无法继续发送数据。如果出现这样的情况，那服务端是不是就要一直保持长连接呢？打个不恰当的比方，是不是有十万名游客来到故宫旅游，就要给故宫装十万个马桶呢？
2023-02-24 14:30:00
993
原创 支付系统中的设计模式09：组合模式
假设现在用户在电商平台购买了一些商品，这些商品都是来自于不同商家。商家收到订单后会把用户买的东西发物流，然后再一个个地发到用户手上。如果此时平台也给用户推送一个发货单的消息，那么这个发货单的数据该怎么「造」出来呢？
2023-02-24 12:30:00
528
原创 用Netty实现物联网05：实现数据采集功能
为什么明明自定义了协议消息体，却没有显示出来呢？这是因为虽然已经自定义了协议消息体，但并没有告诉Netty该如何解析——这就像给了某人一本英语书却没教他怎么学英语一样。而这种对协议的解析，就是编码/解码器的专职工作。
2023-02-24 12:00:00
1077
原创 用Netty实现物联网04：自定义通信协议
大多数硬件电子产品，都自带了嵌入式软件，或者说固件。这些嵌入式软件/固件基本上都是用C/C++编写的。由于这些小微电子设备资源极其有限，所以它们的通讯方式和协议也极为简单：99.99%都只支持TCP/UDP通讯协议，HTTP根本不在考虑之列。但同时，这些电子设备数量庞大，通讯频繁，尤其是大型基建设施，如水坝、核电站、火车站、塔台等设备运行状态的实时数据，尤为重要，甚至延误、丢失一秒钟的数据都会造成重大事故。由于Netty对TCP/UDP全方位的支持、良好的性能和成熟的社区，使它成为了这方面应用开发的不二选择
2023-02-24 10:00:00
868
原创 用Netty实现物联网03：一个Netty的例子
在摸到RPC的小院和大门（XML-RPC、JSON-RPC和gRPC）之后，就进到RPC的「家里」来做客了。招待咱们的就是Netty——一个可以代表RPC的话事人。官方对Netty的定义是：一个异步事件驱动的网络通信框架。Netty之所以这么重要，是因为XML/JSON-RPC、gRPC都有Netty的身影。不仅如此，RocketMQ、Dubbo、Hadoop、Spring5响应式编程、Elasticsearch、IoT、WebSocket等等，它们的底层实现都离不开Netty的支持。
2023-02-24 09:30:00
527
原创 用Netty实现物联网02：gRPC
如果说之前的XML-RPC和JSON-RPC只是Demo级别的玩具的话，那么gRPC则是真正的RPC大「门」——它是谷歌推出的高性能、开源和通用的RPC框架，它的底层由HTTP/2、Protobuf和Netty等提供技术支撑。gRPC通过IDL（Interface Definition Languagee，接口定义语言），定义可以远程调用的方法、参数和返回类型。
2023-02-24 08:00:00
349
elasticsearch常用命令脚本
2022-11-26
Spring boot Could not resolve placeholder
2017-09-08
TA创建的收藏夹 TA关注的收藏夹
TA关注的人