<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[猎户星座]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/qq_24313635</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; qq_24313635]]></copyright><item><title><![CDATA[Prometheus之简介]]></title><link>https://blog.csdn.net/qq_24313635/article/details/139162760</link><guid>https://blog.csdn.net/qq_24313635/article/details/139162760</guid><author>qq_24313635</author><pubDate>Fri, 24 May 2024 09:19:15 +0800</pubDate><description><![CDATA[通过图解的方式，分别介绍了 Prometheus 的优势和劣势、指标收集、采集方式、Exporter、PromQL、监控告警，希望能给大家云原生的监控之路上带来一些启发~]]></description><category></category></item><item><title><![CDATA[SkyWalking之Agent原理]]></title><link>https://blog.csdn.net/qq_24313635/article/details/139093014</link><guid>https://blog.csdn.net/qq_24313635/article/details/139093014</guid><author>qq_24313635</author><pubDate>Tue, 21 May 2024 15:00:59 +0800</pubDate><description><![CDATA[Java Agent本质上可以理解为一个插件，该插件就是一个特制的Jar包。这个Jar包通过JVMTI（JVM Tool Interface）完成加载，最终借助JPLISAgent（Java Programming Language Instrumentation Services Agent）完成对目标代码的修改实现一个JavaAgent:JavaAgent有两种加载模式：静态加载，动态加载；]]></description><category></category></item><item><title><![CDATA[Java Agent]]></title><link>https://blog.csdn.net/qq_24313635/article/details/139084396</link><guid>https://blog.csdn.net/qq_24313635/article/details/139084396</guid><author>qq_24313635</author><pubDate>Tue, 21 May 2024 10:06:57 +0800</pubDate><description><![CDATA[Java Agent 直译为 Java 代理，也常常被称为 Java 探针技术。Java Agent 是在 JDK1.5 引入的，是一种可以动态修改 Java 字节码的技术。Java 中的类编译后形成字节码被 JVM 执行，在 JVM 在执行这些字节码之前获取这些字节码的信息，并且通过字节码转换器对这些字节码进行修改，以此来完成一些额外的功能。Java Agent 是一个不能独立运行 jar 包，它通过依附于目标程序的 JVM 进程，进行工作。]]></description><category></category></item><item><title><![CDATA[日志全链路追踪之MDC]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136643737</link><guid>https://blog.csdn.net/qq_24313635/article/details/136643737</guid><author>qq_24313635</author><pubDate>Tue, 12 Mar 2024 10:17:27 +0800</pubDate><description><![CDATA[Hi，大家好，我是有清苏格拉底说过：日志打得好，排查没烦恼我们日常的开发工作中，排查问题去看日志应该是家常便饭的事，日志可以帮助我们清楚的知道当前代码的走向以及链路数据，通常我们现在都是微服务的架构，那么在我们 A 系统调用到 B 系统中，B 系统又调用 C 系统在繁忙的日志中，我们如何全链路追踪一笔调用呢，通常我们会借助到全局流水号这样的概念，例如下图这样。]]></description><category></category></item><item><title><![CDATA[JVM常用参数]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136341518</link><guid>https://blog.csdn.net/qq_24313635/article/details/136341518</guid><author>qq_24313635</author><pubDate>Wed, 28 Feb 2024 11:26:02 +0800</pubDate><description><![CDATA[要设置好各种 JVM 参数，还可以对 server 进行压测， 预估自己的业务量，设定好一些 JVM 参数进行压测看下这些设置好的 JVM 参数是否能满足要求。经过前面对 JVM 参数的介绍及相关例子的实验，相信大家对 JVM 的参数有了比较深刻的理解，接下来我们再谈谈如何设置 JVM 参数。输出详细的 GC 收集日志信息。测试时候，可以将参数调到最小，定义一个大对象，撑爆堆内存，参数不懂，推荐直接去看官网。]]></description><category></category></item><item><title><![CDATA[处理Full GC]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136341175</link><guid>https://blog.csdn.net/qq_24313635/article/details/136341175</guid><author>qq_24313635</author><pubDate>Wed, 28 Feb 2024 11:16:52 +0800</pubDate><description><![CDATA[]]></description><category></category></item><item><title><![CDATA[Minor GC、Major GC和Full GC]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136338768</link><guid>https://blog.csdn.net/qq_24313635/article/details/136338768</guid><author>qq_24313635</author><pubDate>Wed, 28 Feb 2024 10:21:48 +0800</pubDate><description><![CDATA[Full GC（Full Garbage Collection）是Java虚拟机中进行垃圾回收的一种操作，它的目标是清理整个Java堆内存，包括年轻代（Young Generation）、年老代（Old Generation或Tenured Generation）、以及永久代（在Java 8及之前的版本中，而在Java 8及之后的版本中由Metaspace取代，所以这里可以理解为元空间Metaspace）。]]></description><category></category></item><item><title><![CDATA[JVM性能调优详解]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136316298</link><guid>https://blog.csdn.net/qq_24313635/article/details/136316298</guid><author>qq_24313635</author><pubDate>Tue, 27 Feb 2024 10:38:56 +0800</pubDate><description><![CDATA[则其他堆空间的分配，基于以下规则来进行。一般是从满足程序的内存使用需求开始的，之后是时间延迟的要求，最后才是吞吐量的要求，要基于这个步骤来不断优化，每一个步骤都是进行下一步的基础，不可逆行之。评估当前吞吐量和目标差距是否巨大，如果在20%左右，可以修改参数，加大内存，再次从头调试，如果巨大就需要从整个应用层面来考虑，设计以及目标是否一致了，重新评估吞吐目标。通过以上原则，我们发现，其实最有效的优化手段是架构和代码层面的优化，而JVM优化则是最后不得已的手段，也可以说是对服务器配置的最后一次“压榨”。]]></description><category></category></item><item><title><![CDATA[JVM三色标记算法]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136281447</link><guid>https://blog.csdn.net/qq_24313635/article/details/136281447</guid><author>qq_24313635</author><pubDate>Sun, 25 Feb 2024 13:35:09 +0800</pubDate><description><![CDATA[三色标记法，主要是为了高效的标记可被回收的内存块。白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代 表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对 象不可能直接（不经过灰色对象）指向某个白色对象。灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。]]></description><category></category></item><item><title><![CDATA[CPU指令乱序执行]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276466</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276466</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:50:00 +0800</pubDate><description><![CDATA[说了这么多，很可能在我之后的文章中被一句话带过。其实我想表达的思想就是，实际代码运行的顺序可能和我们代码编写的顺序并不一致。记住这句话很容易，但或许总会有人像我一样想稍微深入一点来了解这句话的本质吧。除了本文所述，CPU和高速缓存之间的交互过程中，硬件工程师也着实给软件开发者挖了不少坑，内存屏障就是在这种背景下产生的。]]></description><category></category></item><item><title><![CDATA[CPU缓存一致性协议原理]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276449</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276449</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:49:03 +0800</pubDate><description><![CDATA[一个long类型的x是8个字节，这2个x位于同一个缓存行的概率极大（尤其这2个x位于同一个数组，在内存中是挨着的），2个cpu分别修改一个x，2个x在一方cpu都有缓存，修改了其中一个需要通知另外一个，每改一次通知一下，总之在修改的时候需要触发一种机制需要另外的cpu跟我保持一致，如果这样的话，耗时当然会比较长。当要访问一个数据的时候，干脆每一次缓存一小块的数据，这一小块数据里面包含了整个数组的数据，当访问数组中的任意元素数据的时候，就可以直接从缓存中读取到了，这一块的数据被称为缓存行。]]></description><category></category></item><item><title><![CDATA[JVM级别内存屏障如何禁止指令重排序]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276432</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276432</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:47:55 +0800</pubDate><description><![CDATA[为什么有一个空指令存在，因lock指令在锁总线的时候，这条指令后面必须跟一条指令，后面指令不能为空，所以后面得跟一条指令，但是后面跟的又不能有任何作用，如果有任何作用，中间改了别的值，也不对，所以设计了这么一个指令，往某个寄存器上加了个0，跟没有操作一样，主要为了迎合lock指令的参数要求即后面必须跟一个指令，其实只要有一个lock指令就足够了。java写的volatile，jvm编译执行，java是解释执行的，所以要想了解volatile怎么实现的，得去读hotspot解释器的代码，看是怎么解释完成的？]]></description><category></category></item><item><title><![CDATA[Seata-TCC模式]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276392</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276392</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:44:29 +0800</pubDate><description><![CDATA[下单请求给到事务协调者，首先调用订单服务Try方法执行下单中的逻辑，然后调用库存服务，锁定库存，事务协调者如果没有收到问题反馈，就调用每个具体服务的Confirm，即调用订单服务Confirm执行支付逻辑，调用库存服务Confirm执行扣减库存的逻辑，如果扣减库存出问题了，就调用订单服务的Concel执行未支付或回滚的逻辑。TCC是二阶段提交协议，Try-Confirm-Cancel（资源预留、确认操作、取消操作），Try是对当前业务资源的检查，如果成功，则Confirm提交，否则Cancel回滚。]]></description><category></category></item><item><title><![CDATA[Seata-Saga模式]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276373</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276373</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:43:29 +0800</pubDate><description><![CDATA[XA和AT都是数据源代理，业务侵入型少；比如图1中这3个完全没有关系的服务，在总业务逻辑处理的时候，使用Saga的状态机来定义，调用服务1，再调用服务2，再调用服务3。Seata中的Saga事务模式是由外部的Saga提供的状态机来进行完成的，需要定义总流程，状态机里可以定义当前节点的调用服务，而且每个节点上可以配置当前这个调用服务的反向补偿节点。一阶段正向执行，比如T1和T2正常，T2到T3也正常，T3位置出现问题了， 就需要整体的回滚，这个时候就会进行反向补偿，把之前的已成功的状态都补偿回去。]]></description><category></category></item><item><title><![CDATA[Seata-XA模式]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276355</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276355</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:41:50 +0800</pubDate><description><![CDATA[如果库存减1了，订单并没有真正创建，这个时候读库存，读到的确实是99，这个99就是所谓的中间状态，这个就是脏读。AT、SAGA、TCC都是补偿型的，都会出现脏读的情况，当然Seata本身是有预防的，但确实会存在这些问题：可能会得到脏数据且最终一致性是允许有中间状态的，这也解释了为什么Seata支持XA，因为XA是强一致性的。如果一个参与全局事务的RM资源失联了，收不到分支事务的结束命令，那它锁定的数据就会被一直锁定，就有可能会产生死锁，这是XA协议要解决的核心问题，也是Seata引入XA模式要解决的问题。]]></description><category></category></item><item><title><![CDATA[Seata-AT模式]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136276339</link><guid>https://blog.csdn.net/qq_24313635/article/details/136276339</guid><author>qq_24313635</author><pubDate>Sat, 24 Feb 2024 21:40:27 +0800</pubDate><description><![CDATA[一阶段，会拦截业务sql（比如订单先调用库存（库存减1），再生成订单），Seata解析sql语句，同时要找到当前要更新的业务数据，比如库存减1，在数据被更新前，保存undolog日志，再执行业务sql，更新之后的数据再保存到redolog日志。回滚的时候所用到的数据就在undolog，即在数据被正式更新之前所保存下来的原数据作为回滚的依据，通过回滚反向生成sql完成分支事务的回滚，事务结束后会释放所有资源和删除所有日志。TM发起全局事务的执行，不同的分支事务需要执行自己的本地事务。]]></description><category></category></item><item><title><![CDATA[支付系统高可用架构设计实战]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136259367</link><guid>https://blog.csdn.net/qq_24313635/article/details/136259367</guid><author>qq_24313635</author><pubDate>Fri, 23 Feb 2024 16:34:23 +0800</pubDate><description><![CDATA[对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全不间断运行可以说“难于上青天”。为此，对应用可用性程度的衡量标准一般有3个9到5个9。对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，宜信支付系统从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，宜信支付系统的服务能力可以达到99.999%。]]></description><category></category></item><item><title><![CDATA[防重复提交]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136251335</link><guid>https://blog.csdn.net/qq_24313635/article/details/136251335</guid><author>qq_24313635</author><pubDate>Fri, 23 Feb 2024 11:22:25 +0800</pubDate><description><![CDATA[配合使用的防重复提交的实现。但是这个方案有个小弊端。仅生效于有RequestBody注解的参数，因为使用RequestBodyAdvice来实现。但是大部分我们需要做请求防重复提交的接口一般都是POST请求，且有requestBody。注解即可，interval即多久的间隔内相同参数视为重复请求。类来实现代码实现更加简洁，配置更加简单。通过在Controller上打上。这种防请求重复提交的实现有基于。最后考量下笔者认为利用。]]></description><category></category></item><item><title><![CDATA[数据库乐观锁]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136212952</link><guid>https://blog.csdn.net/qq_24313635/article/details/136212952</guid><author>qq_24313635</author><pubDate>Wed, 21 Feb 2024 15:26:53 +0800</pubDate><description><![CDATA[从本质上讲，乐观锁是在首次读取或访问数据记录进行潜在更新，但实际上并未锁定数据记录。使系统在乐观的假设下运行，即冲突很少且不会经常发生。仅当即将提交实际更新时，系统才会检查冲突。如果数据同时被另一个事务更改，则当前更新失败。第一步是向您的实体添加版本字段并使用 @Version 对其进行注解。该字段通常可以是整数或时间戳。@Entity@Id@Version在此设置中，JPA 将使用版本字段来跟踪每个产品实体的更改。]]></description><category></category></item><item><title><![CDATA[交易流水号的艺术：掌握支付系统的业务ID生成指南]]></title><link>https://blog.csdn.net/qq_24313635/article/details/136174639</link><guid>https://blog.csdn.net/qq_24313635/article/details/136174639</guid><author>qq_24313635</author><pubDate>Mon, 19 Feb 2024 17:09:26 +0800</pubDate><description><![CDATA[数据库一般都会设计一个自增ID做为主键，同时还会设计一个能唯一标识一笔业务的ID，这就是所谓的业务ID（也称业务键）。比如收单域有收单单号，支付域有支付号，渠道网关域有渠道支付号等，这些都属于业务ID。为什么有了自增ID后，还需要有业务ID呢？]]></description><category></category></item></channel></rss>