- 博客(139)
- 资源 (1)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 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
378
1
原创 JVM系统优化实践（16）：线上GC案例（一）
一般新手工程师在部署生产环境时基本不会对JVM进行设置，基本跟上也都是使用JVM的默认设置，这是一个很大的隐患。例如，如果不设置-Xmx或者-Xms的话，可能初始的年轻代和老年代就几百M大小。Full GC一般在正常情况下，都是按天为单位来发生的，比如每天一次，或几天一次Full GC。
2023-04-18 07:30:00
100
原创 JVM系统优化实践（15）：GC可视化工具实践
线上系统的JVM监测要么使用jstat、jmap、jhat等工具查看JVM状态，或者使用监控系统，如Zabbix、Prometheus、Open-FaIcon、Ganglia等。作为一个工具人，怎么能不懂jstat、jmap、jhat呢？
2023-04-10 07:30:00
279
原创 JVM系统优化实践（14）：GC可视化工具
工欲善其事，必先利其器。知道了GC工作原理，学会了看GC日志之后，再来了解一下分析GC的工具。它们分别是jstat、jmap、jhat。
2023-04-07 07:30:00
103
原创 JVM系统优化实践（13）：GC动手实践
上一次留了个小尾巴：怎么以通过代码模拟对象年龄在15岁之后才进入老年代呢？自己试着实现了一下。然后再结合之前了解的其他GC知识，来模拟更多的触发GC的实例。
2023-04-03 07:30:00
70
原创 JVM系统优化实践（12）：GC日志分析
了解了基本的G1垃圾回收机制以后，就可以结合实际日志分析一下它的日志内容了，以后再遇到问题自己也能看懂。
2023-03-27 21:38:29
476
原创 JVM系统优化实践（11）：GC如何搞垮线上系统
看了那么多G1 GC的传说，再来看看一些具体的GC案例以及怎么预防GC把工程师精心设计的系统给搞垮。
2023-03-23 07:30:00
243
原创 JVM系统优化实践（10）：G1混合回收
G1替代了ParNew+CMS这对搭档组合，既能实现年轻代的垃圾回收，也能实现老年代的垃圾回收。现在继续来说说它的混合回收问题。
2023-03-21 07:30:00
69
原创 JVM系统优化实践（9）：G1垃圾回收器
在JDK8及其之前，一直用的都是ParNew+CMS的组合：ParNew负责年轻代的垃圾回收，而由CMS负责老年代的垃圾回收，但会产生Stop the World这个无法避免的问题。
2023-03-08 07:48:19
197
原创 JVM系统优化实践（8）：订单系统的垃圾回收案例
上回说到了年轻代和老年代的两个垃圾回收器：ParNew和CMS，并且将CMS的GC过程也一并介绍了，现在来看个订单系统的案例。
2023-03-06 06:58:11
285
原创 JVM系统优化实践（7）：垃圾回收器与垃圾回收算法
上回说到了年轻代、老年代与数据计算的一个案例。接下来就先讲一讲年轻代和老年代的两个垃圾回收器：ParNew和CMS。
2023-03-04 07:30:00
312
原创 JVM系统优化实践（6）：年轻代、老年代与数据计算
如果当前Survivor区中年龄相同的一批对象总大小 ≥ Survivor总数× 50%，那么这批对象及比它们年龄更大的对象，就都直接进入老年代。但是也有可能在Minor GC之后，发现剩余的存活对象太多，导致其大小总和超过Survivor区域，那么就会把这些对象直接转移到老年代，也不计算所谓的50%。
2023-03-02 07:30:00
85
原创 JVM系统优化实践（5）：什么时候GC以及有哪些GC
既然程序运行会产生大量的废弃物，也就是「垃圾」，那总不能一直堆着不管吧。现在就来粗浅地谈谈Java里面什么时候会触发GC以及有哪些GC。
2023-02-28 07:30:00
250
原创 架构师怎么做管理：接口文档管理
任何一个优秀的互联网系统，都离不开各类研发岗位上工程师们的通力协作，而且这种协作必须是以高效的、低成本的沟通方式进行。软件开发从过去的小作坊到现在几十几百人，到现在成千上万人的同时参与，这里面如果没有一个好的协作工具，是不可能进行下去的。对于工程师来说，开发文档就是这样一个低成本、高效率的沟通工具。但奇怪的是，很多工程师都不愿意写文档，尤其是开发文档（或者说接口文档），因为他们觉得只要有技术就可以了，文档啥的有没有都无所谓。
2023-02-27 18:00:00
254
原创 基于SpringCloud的可靠消息最终一致性06：轮询事务消息
对于同一个事务消息，在正常情况下它要被发送至少两次。这是因为在发送消息之前，TransactionMessageService就已经把消息保存到了数据库中。而在首次消费完消息后，TransactionMessageListener并没有从数据库中删掉，数据库中保存的消息，将被轮询服务AppListenerScheduleExecutor再次发送。
2023-02-27 17:00:00
234
原创 基于SpringCloud的可靠消息最终一致性05：保存并发送事务消息
在有了分布式事务的解决方案、项目的需求、骨架代码和基础代码，做好了所有的准备工作之后，接下来就可以继续深入了解「核心业务」了。
2023-02-27 16:00:00
293
原创 基于SpringCloud的可靠消息最终一致性04：项目基础代码
好的架构其实是慢慢演变出来的，但良好的面向对象特性，一定是设计出来的。从图中可以看出，这里又为每个层次定义一个父类，并继承自BaseObject。例如BaseEntity表示所有实体类的父类，继承自BaseObject；BaseService表示所有服务类的父类，也继承自BaseObject。这样做可以将职责更加细化，可以参照Java中的集合类继承结构。
2023-02-27 15:00:00
216
原创 基于SpringCloud的可靠消息最终一致性03：项目骨架代码（下）
由于项目使用了MySQL、MongoDB、Redis、ActiveMQ、Nacos等中间件，这里就不一一安装了。基本骨架搭建完毕之后，下一步就可以开始充实内容了。
2023-02-26 11:00:00
365
原创 基于SpringCloud的可靠消息最终一致性02：项目骨架代码（上）
之前已经把分布式事务问题交代了一遍，包括两大定理、五大解决方案和一个成熟的开源框架，而咱们最终的目标是用SpringCloud实现一个实际创业项目的可靠消息最终一致性的分布式事务方案。
2023-02-26 09:00:00
439
原创 基于SpringCloud的可靠消息最终一致性01：定理、解决方案和框架
很多同学都知道分布式事务很好很强大，而且互联网上也有很多分布式事务的相关理论和解决办法，例如CAP、BASE、2PC、TCC、XA、最大努力通知、柔性事务等等，但这些理论全都缺少完整的实际案例作为参考指引（这里说的「实际案例」，不是指的几段代码，或者一两个类文件，而是指从数据库设计到最后可以部署的完整项目），所以好多人也就不知道该怎么结合实际业务场景来实践它们。
2023-02-26 07:30:00
301
原创 JVM系统优化实践（4）：以支付系统为例
前面说过，JVM会将堆内存划分为年轻代、老年代两个区域。年轻代会将创建和使用完之后马上就要回收的对象放在里面，而老年代则将创建之后需要长期存在的对象放在里面。那么现在再来看一个比较具体的例子。
2023-02-26 07:30:00
314
原创 规则引擎与风控系统05：其他规则引擎
其实更复杂的基于规则的风控系统也都是从简单到复杂慢慢演化出来的。虽然Drools很强大，但它也不是唯一的规则引擎，还有另外两个也同样出色，它们是Groovy和Aviator。
2023-02-25 15:00:00
439
原创 规则引擎与风控系统04：风控系统实例（下）
上一节把风控实例的基础代码都撸了出来。接下来再来把核心服务代码和规则文件写出来。因为有了实体类、Dao，所以接来下就可以写服务类了。之前说过这个实例就是要实现两个目的：1、一分钟内连续访问三次以上，就会被直接封杀；2、黑名单用户登录会记录可疑事件。
2023-02-25 14:00:00
285
原创 规则引擎与风控系统03：风控系统实例（上）
就笔者个人创业经验，对小公司而言，最快最有效的风控手段可能就是「事件监控」和「黑名单」这两种了。原因就是简单好实现，而且实现成本几乎可以忽略不计。至于之前介绍的那些「标准/风控模型」，是在有了团队、技术及资金支持（也就是有钱了，有人了，可以想怎么折腾都行了）的情况下，才能着手实施的。而且「黑名单」也是基本上来源于「事件监控」。
2023-02-25 11:00:00
421
原创 规则引擎与风控系统02：规则引擎
由于运行规则总是会变来变去，而技术同学又不想每次规则变化就改一次代码然后变成地中海。也就是说，必须有一种技术手段，将活动规则和代码进行解耦，不管规则怎么变，代码都不用改。真有可以这么神奇么？——确实有一种这样的「解耦」技术，那就是「规则引擎」。所谓「规则引擎」，根据某百科的解释是：「是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。它接受数据输入，解释业务规则，并根据业务规则做出业务决策」。
2023-02-25 10:00:00
330
原创 规则引擎与风控系统01：新问题，新挑战
有些行为（比如薅羊毛）虽然没有病毒、木马、漏洞等攻击来的直接，但是如果一直被黑灰产（羊毛党、刷单党等）长期吸血，企业生存下来的几率也会很低，而且这些也会严重影响正常用户的体验和利益。基于此，互联网平台借鉴了金融行业中的「风控」（风险控制）机制，主要是对欺诈和作弊行为采取了有针对性的应对策略，而不再像过去那样只知道救火。
2023-02-25 07:30:00
347
原创 用Netty实现物联网07：提升系统性能
之前的业务需求明确了需要区分终端的在线或离线状态。由于在Netty中，客户端与服务端连接时都会启动一个新的线程，在每个线程中都有唯一的ChannelHandlerContext对象，它是当前客户端连接的唯一通道。所以，可以利用这个唯一通道和客户端的IMEI号实现会话管理。
2023-02-24 16:00:00
353
原创 用Netty实现物联网06：自动断开连接与自定义指令
在实际项目的运行中，硬件并不是时时刻刻都在发送数据，而是会按照设定的时间间隔，有规律地传输。或者有些硬件终端因为故障、电源耗尽而无法继续发送数据。如果出现这样的情况，那服务端是不是就要一直保持长连接呢？打个不恰当的比方，是不是有十万名游客来到故宫旅游，就要给故宫装十万个马桶呢？
2023-02-24 14:30:00
449
原创 支付系统中的设计模式09：组合模式
假设现在用户在电商平台购买了一些商品，这些商品都是来自于不同商家。商家收到订单后会把用户买的东西发物流，然后再一个个地发到用户手上。如果此时平台也给用户推送一个发货单的消息，那么这个发货单的数据该怎么「造」出来呢？
2023-02-24 12:30:00
446
原创 用Netty实现物联网05：实现数据采集功能
为什么明明自定义了协议消息体，却没有显示出来呢？这是因为虽然已经自定义了协议消息体，但并没有告诉Netty该如何解析——这就像给了某人一本英语书却没教他怎么学英语一样。而这种对协议的解析，就是编码/解码器的专职工作。
2023-02-24 12:00:00
746
原创 用Netty实现物联网04：自定义通信协议
大多数硬件电子产品，都自带了嵌入式软件，或者说固件。这些嵌入式软件/固件基本上都是用C/C++编写的。由于这些小微电子设备资源极其有限，所以它们的通讯方式和协议也极为简单：99.99%都只支持TCP/UDP通讯协议，HTTP根本不在考虑之列。但同时，这些电子设备数量庞大，通讯频繁，尤其是大型基建设施，如水坝、核电站、火车站、塔台等设备运行状态的实时数据，尤为重要，甚至延误、丢失一秒钟的数据都会造成重大事故。由于Netty对TCP/UDP全方位的支持、良好的性能和成熟的社区，使它成为了这方面应用开发的不二选择
2023-02-24 10:00:00
432
原创 用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
232
原创 用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
99
原创 用Netty实现物联网01：XML-RPC和JSON-RPC
和（移动）互联网不同，物联网针对的主要是一些资源有限的硬件设备，比如监控探头、烟雾感应器、温湿度感应器、车载OBD诊断器、智能电表、智能血压计等。这些硬件设备既不像个人PC电脑那样拥有较为齐全的配套支持，也不像手机那样灵活、方便、可操控，它们除了能够接受输入指令以及向外输出响应数据之外，基本上就是等于是「沉默的大多数」。所以，为了实现这些「沉默」的电子设备之间的「物物相连」和「人物相连」，实现对它们的感知、识别和管理，物联网（Internet of Things）就因此而诞生了。
2023-02-24 07:30:00
204
原创 JVM系统优化实践（3）：分代模型
大部分在代码里创建的对象，存活周期都是极短的，只有少数对象是长期存活的，如静态类和静态变量。采用不同方式创建和使用对象，其生存周期也不同。因此，JVM将堆内存划分为年轻代、老年代两个区域。
2023-02-24 07:30:00
21
原创 支付系统中的设计模式06：状态模式
在GoF中对状态模式的定位是：状态模式与有限状态机的概念紧密相关，其主要思想是程序在任意时刻仅可处于几种有限的状态中。在任何一个特定状态中，程序的行为都不相同，且可瞬间从一个状态切换到另一个状态。不过，根据当前状态，程序可能会切换到另外一种状态，也可能会保持当前状态不变。这些数量有限且预先定义的状态切换规则被称为转移。
2023-02-23 16:00:00
440
原创 支付系统中的设计模式05：观察者与备忘录模式
某件事情做完以后，如果需要告诉别人结果的话，要么当面告诉别人，要么就打对方电话通知对方。这种事后告诉别人结果的方法在开发里面有个专门有的名词，叫做「回调」。对于回调这个概念，稍微了解设计模式的小伙伴可能都知道哪个模式和它对应吧。
2023-02-23 15:30:00
165
原创 支付系统中的设计模式04：改进的策略与外观模式
随着业务越做越大，交易量大了，老板就提了这样的需求：支付系统需要根据不同的结算模式，返利给账户：1、选择T+1结算方式的，给账户返利订单金额的0.1%；2、选择T+7结算方式的，给账户返利订单金额的0.3%。你可能会想：这不就是简单的if...else嘛，直接写代码就好了。然鹅，老板如果继续心血来潮，想搞T+2、T+3、......、T+8、T+9、......、T+30......，咋办？
2023-02-23 15:00:00
735
原创 支付系统中的设计模式07：责任链模式
作为一种行为设计模式，责任链模式可以将请求沿着处理者链进行发送。收到请求后，每个处理者均可对请求进行处理，或将其传递给链上的下一个处理者。举个例子，假设用户可以在平台上下单购买商品，而且后台运营人员也有权限访问用户创建的订单。如果后续需要增加一些订单验证步骤，比如同一个IP一天内只能下单一次、通过规则引擎判断订单是否存在刷单嫌疑、判断多级缓存中的订单是否一致等等。这样的话，每次新增一些看似必要的功能都会让代码变得更加臃肿混乱，维护困难。
2023-02-23 10:06:56
664
原创 支付系统中的设计模式08：迭代器模式
用户下单购买的商品清单肯定是一个列表，而所谓的抽检其实就是要遍历这个列表中的每个元素，然后看看有无敏感商品或刷单行为（比如连续购买了多个同类的活动商品，并且下单时间极为接近，但这里不考虑这些）。最容易想到的方法就是直接用for循环检察列表，这的确是最直接的办法，但笔者还是要重复前面讲过的：在有了简单的、容易想到的办法后，至少还要再深入思考一下还有没有别的更好的方法可以替代呢？
2023-02-23 10:05:20
529
elasticsearch常用命令脚本
2022-11-26
Spring boot Could not resolve placeholder
2017-09-08
TA创建的收藏夹 TA关注的收藏夹
TA关注的人