【欢迎关注公众号：冬瓜白】

IP地址和域名各有优劣，选择哪种方式取决于具体的应用场景和需求。在分布式系统中，IP地址更适合内网和容器化环境，能够提供高效的性能和动态适配能力；在实际应用中，可以根据需求灵活选择，甚至结合两者，以实现最佳的服务寻址方案。在微服务架构中，服务实例可能分布在不同的机器、集群甚至数据中心中。本文将从性能、稳定性、动态性、可读性、灵活性、安全性等多个角度，详细分析IP地址和域名的优缺点，并探讨它们在分布式系统中的应用。无论选择哪种方式，核心目标都是确保服务的高效、稳定和可维护。那么，哪种方式更好呢？

本文探讨了一个在项目迁移过程中遇到的性能问题：FreeMarker 视图首次渲染速度慢。使用了 Trace 分析和 Async-profiler 工具定位到问题后，然后提出了三种可能的优化策略。最终选择了预加载资源的策略，并使用 Spring 提供的来实现。优化结果非常显著，首次渲染的时间从4秒以上降低到了0.2秒以上。

这是因为在 Struts2 中，当一个 Action 被调用时，Struts2 会尝试将 HTTP 请求的参数绑定到 Action 的属性。这个过程是通过调用 Action 的 setter 方法完成的。这里完全可以改成基于 setter 方法进行参数绑定，那么就可以实现跟 Struts2 类似的“预初始化属性”机制。函数的预初始化属性和请求中的 repairVO.xxx 属性。也就实现了预初始化属性的设置。所以后端 Struts 的 Action 的成员属性会接收。居然还有其他的属性也有值。

既然要迁移，那必然要对 Struts2 和 FreeMarker 这样的技术有一定的了解。不过在 Spring Boot 大行其道的今天，以及越来越多的前后端分离开发模式，SSH 早已风光不再，很多年轻的同学甚至都不知道 Struts2，如果快速的了解 Struts2 和 FreeMarker 这种模版引擎呢？本文实现了一个非常简单的 Struts，支持简单的参数绑定和 JSP 页面的渲染。也提到过，由于服务的拆分，后续会将我们现在的 Web 应用改造成结合了静态页面渲染和动态数据交互的。

最近在做一个事：下线一个超级大单体服务。单一统计代码行数其实不够全面，反正项目 git clone 下来文件就有这么大：这是一个已经存在了十年以上的服务，随着业务的发展，这个服务已经无法满足我们的需求。我们统计了一下，有近 400 个页面菜单需要迁移到已经划分好领域的各个微服务之中。其实最麻烦的还是前端页面，因为页面重写是比较麻烦的，涉及到大量的细节梳理，可能还需要前端、设计和产品同学的介入，想在 1 年甚至几个月全部重写完成在有限的资源情况下是不可能完成的任务。所以我提出了一个方案，

负载最低优先” 的负载均衡策略在分布式系统中非常常见，目的是将负载较低的服务器优先分配请求，以确保资源的最佳利用。负载最低优先可以使用如最小连接数、CPU/IO 负载等。但也要注意的是这种策略会极大增加系统的复杂度，这里引入《从零开始学架构》中的介绍：负载最低优先算法基本上能够比较完美地解决轮询算法的缺点，因为采用这种算法后，负载均衡系统需要感知服务器当前的运行状态。当然，其代价是复杂度大幅上升。

上周组内周会大家讨论到了 MySQL 的主从同步。正好借着这个议题，开启一个新的系列，探讨一下分布式环境中集群数据同步的设计，如 Redis、ZooKeeper、RocketMQ、Eurake、MySQL 等。开源中间件都很复杂，抓大放小，所以仅分析这三点在各个中间件中的实现设计。本文探讨的是 ZooKeeper。先说明一个基本概念，ZK 并不是传统意义上的 Master/Slave 模式，而是引入了 Leader、Follower 和 Observer 三种角色概念。

思路比解决方案更重要。

兼容是本次分库分表项目中非常重要的一点，本文探讨的议题是兼容中的事务问题。实在是不知道这个标题名称该怎么取。直接看一个例子吧，这也是是很多朋友经常有疑问的一个点。这个方法非常简单，一个被标注的方法，内部调用了两个配置了不同数据源和事务管理器的Mapper，要注意的是，这里的并未设置任何参数，即属性参数都用默认的。那么这个方法在执行后，是会回滚还是会回滚呢？.....................

相关文章：上周测试同学反馈的一个 BUG，订单根据用户姓名查询不出来，我本地复现后发现情况更复杂，问题具体表现为：多次查询，大部分情况下都无法查询数据，偶尔可以查询到数据。排查后发现与我们项目中使用的 MyBatis 加解密拦截器有关，加解密拦截器的作用是敏感字段储存数据库的时候会进行加密，查询的时候会对数据库的中的加密数据进行解密，如果查询条件中包含敏感字段，会先将敏感字段加密后再到数据库中进行查询。大致执行流程为：要注意的是这个项目的加解密拦截器在执行完成之后是并不会将加密参数进行恢复的。但由于当前分库

昨晚跟朋友（马儿）撸串的时候又聊起了分布式事务，这里炒一个冷饭，发一下去年在部门内部分享的《从单机事务到分布式事务》文档。单机事务事务的特性Atomicity（原子性）Isolation（隔离性）Durability（持久性）Consistency（一致性）MySQL InnoDB 事务实现原理MVCC+锁+logMVCC（无锁）隐藏列版本链锁独占锁、共享锁IX，IS范围锁行锁间隙锁、临键锁、记录锁表锁logundo log.

相关文章：自己动手写一个分库分表中间件（一）思考自己动手写一个分库分表中间件（二）数据源定义和分片代理层设计自己动手写一个分库分表中间件（三）数据源路由实现自己动手写一个分库分表中间件（四）表路由、SQL 重写和结果集处理思路自己动手写一个分库分表中间件（五）分布式事务问题解决思路<一>基于 Spring 编程式事务自己动手写一个分库分表中间件（六）分布式事务问题解决思路<二>动态事务管理器一个分布式事务的案例及解决思路分布式事务之 Spring 事务抽象和源码实现

相关文章：自己动手写一个分库分表中间件（一）思考自己动手写一个分库分表中间件（二）数据源定义和分片代理层设计自己动手写一个分库分表中间件（三）数据源路由实现自己动手写一个分库分表中间件（四）表路由、SQL 重写和结果集处理思路自己动手写一个分库分表中间件（五）分布式事务问题解决思路<一>基于 Spring 编程式事务一个分布式事务的案例及解决思路分布式事务之 Spring 事务抽象和源码实现分布式事务之 Atomikos分布式事务之再理解 TCC 及相关实现框架的源码分析（一

相关文章：自己动手写一个分库分表中间件（一）思考自己动手写一个分库分表中间件（二）数据源定义和分片代理层设计自己动手写一个分库分表中间件（三）数据源路由实现自己动手写一个分库分表中间件（四）表路由、SQL 重写和结果集处理思路一个分布式事务的案例及解决思路分布式事务之 Spring 事务抽象和源码实现分布式事务之 Atomikos分布式事务之再理解 TCC 及相关实现框架的源码分析（一）分布式事务之 Spring 编程式事务分布式事务之基于消息（一）最大努力通知分布式事务之基于消息（

相关文章：自己动手写一个分库分表中间件（一）思考自己动手写一个分库分表中间件（二）数据源定义和分片代理层设计自己动手写一个分库分表中间件（三）数据源路由实现注：本文内容暂不涉及事务相关的问题及配置，事务问题会在后面的文章中重点介绍。在分库分表中除了 DataSource 级别的路由，还有表级别的路由，也就是说 SQL 执行可能会访问同一个数据库不同的表。这里就涉及到分表的路由，但是表路由的前提是要先路由到库。表路由中还涉及到一个逻辑表和真实表的概念。逻辑表就是我们写 SQL 时候的表名，

相关文章：自己动手写一个分库分表中间件（一）思考自己动手写一个分库分表中间件（二）数据源定义和分片代理层设计排查项目中读写分离失效原因小议 Java 内省机制注：本文内容暂不涉及事务相关的问题及配置，事务问题会在后面的文章中重点介绍。本文主要介绍分库分表最重要的功能，数据路由的实现。1. 配置解析数据路由第一步是要解析配置，根据两篇文章的介绍，从物理上，或者说 DataSource 的级别，我们是“business+model”构成一个数据源，但是还有分表的配置，所以逻辑上的数据源是

相关文章：自己动手写一个分库分表中间件（一）排查项目中读写分离失效原因分库分表最核心的功能是数据源路由。首先要确定怎么样算是一个数据源。数据源定义选择自研就是为了更适配我们的业务，在上一篇文章《自己动手写一个分库分表中间件（一）》中介绍了我们业务特有的数据源定义：业务1（master+slave+report）/业务2（master+slave+report）/业务3（master+slave+report）在这里 master、slave、report 从 DataSource 的角度

最近在参与一个项目的分库分表改造，底层的分库分表中间件完全自研，截止目前为止，主体功能已经完全开发完成，会逐渐进入测试阶段。后面的系列文章会围绕这个中间件对本次分库分表的改造过程做一个记录。作为系列第一篇文章，主要是谈一些目前这个阶段分库分表改造的个人感想。为什么要分库分表其实这个没啥好说的，放在这里主要是保持一个目录的完整性。之所以要分库分表，很明显是因为库和表都到达了一个瓶颈。至于怎么分，如果是已有项目的改造，一般都是水平拆分，因为垂直拆分会影响现有的业务代码，这个影响程度可能会很大，而且都垂直

相关文章：一次群聊“事件”引发的对 @Transactional 和 MyBatis 的思考最近组内同学遇到了一个场景（先不说这算不算分布式事务），逻辑精简如下：本地事务1（数据源1）本地事务2（数据源2）RPC（非事务操作）有几个细节点：本地事务 1、2 和 RPC 调用之间没有数据依赖 ；本地事务 1 和 2 是两个不同的数据源；RPC 调用失败了需要让本地事务 1 和本地事务 2 回滚；要保证本地事务 1、2 的事务一致性（要么都成功要么都失败）在解决这个问题之前，先

截拳道，指的是不拘于形式，思想上成熟的觉悟，以水为本质而攻击，反击；将一切化解于无形。截拳道的最大特点，是注重于“生活上实际的运用”，抛弃了传统武术复杂的形式套路。相关文章：分布式事务之 Atomikos分布式事务之再理解 TCC 及相关实现框架的源码分析（一）分布式事务之 Spring 编程式事务分布式事务之基于消息（一）最大努力通知前文回顾本文是紧接着上一篇分布式事务之基于消息（一）最大努力通知。在上一篇文章中提到所谓的“最大努力通知”其实本质就是通过一种重试机制去调用下游的服务，.

截拳道，指的是不拘于形式，思想上成熟的觉悟，以水为本质而攻击，反击；将一切化解于无形。截拳道的最大特点，是注重于“生活上实际的运用”，抛弃了传统武术复杂的形式套路。相关文章：分布式事务之 Atomikos分布式事务之再理解 TCC 及相关实现框架的源码分析（一）分布式事务之 Spring 编程式事务之前的几篇文章中已经介绍了分布式事务中的几种方案，本文介绍另外一种经典的方案：基于”消息“的最终一致性方案。既然是基于”消息“，那么一般来说就是异步处理的，就必然会存在”时延“的问题，所以选用这.

最近在回滚分布式事务的一些内容，也与一些同学有了不少讨论。在文章的开头，先表达一个个人的观点：分布式事务是分布式系统中一个常见的问题。我们讨论它主要是为了解决这个问题，而不应该拘泥于某一种“市面上常见的解决方案”或者“某一个框架”。相关文章：分布式事务之 Spring 事务抽象和源码实现分布式事务之 Spring 编程式事务个人觉得 3PC 中的一些思想在 TCC 中也有所体现，所以在步入正题探讨 TCC 之前先看一下 3PC 这一种分布式事务的解决方案。3PC3PC，英文就是 thre.

相关文章：分布式事务之 Atomikos上一篇文章《分布式事务之 Atomikos》中提到了 Atomikos 比较适合实现单服务多数据源的分布式事务场景。那么接下来再看一个分布式事务的场景，这也是很多项目常用的使用方式： /** * 下单 */ @Transactional public void order(){ localOrderService.update(); //本地事务1 localGiftService.update(); //本地事务2，与本地事务1是

关于分布式事务的解决方案被提到最多的就是“TCC”、“基于消息”。但其实还有一种非常经典的解决方案：JTA。而 Atomikos 就是 XA、JTA 那一套的实现，属于 2PC。之前在项目中使用 Atomikos 主要是用来解决单服务多数据源的场景，当然它也可以解决跨服务之间的分布式事务问题。本文主要是从源码的角度简要分析一下 Atomikos 的实现。#Atomikos+Spring Boot+MyBatis+Druid 的使用在网上找了一个 Atomikos+Spring Boot+MyBatis

由于netty通信是异步的，客户端请求之后就不再阻塞等待服务端的结果返回了，客户端可以去做其他的事情，而服务端处理完之后会将响应结果输出给客户端，这些客户端并不知道这个响应结果是属于哪次请求的结果。所有需要一套机制去实现响应结果隶属于是属于哪次调用的结果。通过netty客户端请求服务端流程如下：下面用代码实现一次完整的，rpc通过netty调用之后，找到对应请求的response:首先定义一个netty客户端：public class InvokerClient { priv

SnowFlake是Twitter开源的能够在分布式系统中生成惟一的ID的算法 , 具体介绍本文再也不赘述, 能够参考这篇文章:https://segmentfault.com/a/1190000011282426?utm_source=tag-newestSnowFlake算法生成id的结果是一个64bit大小的整数, 其中的41位时间戳部分依赖服务器的时间, 当服务器发生时钟回拨时, 在开源的实现中不可避免的会出现报错. 关于解决时钟回拨的问题, 网上已有各类方案, 好比适当等待直到时间被追回.

在几年前，负载均衡还是“高端玩家”的游戏，我这种小白还难以触及，现在“负载均衡”已经有点看似烂大街的趋势了。提起负载均衡，首先要理解负载均衡到底是想解决什么样的问题，维基百科有这么一段描述：主要作用是将大量作业合理地分摊到多个操作单元上进行执行，用于解决互联网架构中的高并发和高可用的问题。在现在的互联网系统中，为了避免出现单点问题，最常见的做法就是将系统部署到多台机器上，也就是集群。但是这样会出现两个问题：如何让机器均衡或者相对均衡的接收到到流量；当集群的某个节点宕机，让流量不会打到这个节点

分布式任务调度框架是互联网公司的标配，趁着周末下雨天，自己动手写了一个简版，主要是为了体会其中的原理。框架特点和一些基本功能如下：弹性扩容缩容，理论上可无限扩容，智能负载均衡；Master-Slave 模式，高可用，支持故障转移；调度精度设置；使用简便；其他的比如区分不同项目、任务的动态上下线、任务串行/并行执行、报警重试机制等功能，由于时间原因暂未添加。整个框架设计非常简单：应用在启动后会向注册中心上报任务，调度平台会根据任务生成计划列表，当任务触发后，调度平台会向应用集群下发任务。

文章地址：https://mp.weixin.qq.com/s/-LqQlhGfLOLSGlSQaXWbrA欢迎关注公众号：

转自：https://javatar.iteye.com/blog/1123915?page=2#comments;/* * Copyright 2011 Alibaba.com All right reserved. This software is the * confidential and proprietary information of Alibaba.com ("Co...

转自：https://mp.weixin.qq.com/s/Tgtn2Gs_zwyj5jtKNiRQrA消息队列其实很简单　　“RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词。我也在我的多篇文章中提到了这个概念。可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消...

转自：http://www.cnblogs.com/glacierh/p/5653512.html在分布式存储系统中，数据需要分散存储在多台设备上，数据分片（Sharding）就是用来确定数据在多台存储设备上分布的技术。数据分片要达到三个目的： 分布均匀，即每台设备上的数据量要尽可能相近； 负载均衡，即每台设备上的请求量要尽可能相近； 扩缩容时产生的数据迁移尽可能少。...

转自：https://baijiahao.baidu.com/s?id=1607017969929896292&amp;wfr=spider&amp;for=pc1 、简介什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。如果还是不理解，那么可以举个例子：假如目前有很...

转自：https://blog.youkuaiyun.com/zhengzhaoyang122/article/details/80884535集群容错：集群服务调用失败后，服务框架需要能够在底层自动容错，容错策略很多，分别适用于不同场景。下面将对集群容错的功能和设计进行详细说明。1、集群容错场景    在分布式服务框架中，业务消费者不需要了解服务提供者的具体位置，它发起的调用请求也不包含服务提供...

转自：https://www.oschina.net/question/3665510_2266430 一、I/O优化1、增加缓存，减少磁盘的访问次数。2、优化磁盘的管理系统，设计最优的磁盘方式策略，以及磁盘的寻址策略，这是在底层操作系统层面考虑的。3、设计合理的磁盘存储数据块，以及访问这些数据库的策略，这是在应用层面考虑的。例如，我们可以给存放的数据设计索引，通过...

转自：https://blog.youkuaiyun.com/qq_38366063/article/details/83691424package com.rdd;/** * Twitter_Snowflake&lt;br&gt; * SnowFlake的结构如下(每部分用-分开):&lt;br&gt; * 0 - 0000000000 0000000000 0000000000 00000...

基于上一篇博客：https://blog.youkuaiyun.com/Dongguabai/article/details/83624822完成的RPC框架进行改造，增加基于Curator实现的ZK注册中心。可能这个图不太准确，但是大体意思就是服务端在注册中心中注册服务，客户端在注册中心获取服务地址进行调用，中间可能还会有一些LB等：定义一个注册服务的顶层接口IRegistryCenter...

带注册中心的RPC框架可参看：https://blog.youkuaiyun.com/Dongguabai/article/details/83625362根据资料学习，写了一遍。实现自己的RPC框架如果不需要自定义协议的话那就要基于Socket+序列化。ProcessorHandler：主要是用来处理客户端的请求。package dgb.nospring.myrpc;impor...

RPCRPC（Remote  Procedure  Call，远程过程调用），一般用来实现部署在不同机器上的系统之间的方法调用，使得程序能够像访问本地系统资源一样，通过网络传输去访问远端系统资源；对于客户端来说，传输层使用什么协议，序列化、反序列化都是透明的。 Java RMIRMI 全称是 remote method invocation –  远程方法调用，一种用于远程过程调用的应...

转自：https://www.jianshu.com/p/be66a52d2b9b一、什么是高并发高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Secon...