Category: Java Architecture

[转]携程200T+规模的Redis容器化实践 0

[转]携程200T+规模的Redis容器化实践

背景 携程大部分应用是基于 CRedis 客户端通过集群来访问到实际的 Redis 的实例,集群是访问 Redis 的基本单位,多个集群对应一个 Pool,一个 Pool 对应一个 Group,每个 Group 对应一个或多个实例,Key 是通过一致性 hash 散列到每个 Group 上,集群拓扑图如截图所示。 这个图里面我们可以看到集群,Pool,Group 还有里面的实例,这是携程 Redis 一个比较常见的拓扑图,如下图: 为什么要容器化 标准化和自动化 Redis 之前是直接部署在物理机上,而 DBA 是根据物理机上设定的 Redis 的版本来选择需要部署的物理机,携程的各个版本的 Redis 非常分散而且不容易维护,如下图所示,容器天然支持标准化,另外容器基于 K8S...

[转]Netty学习和进阶策略 0

[转]Netty学习和进阶策略

背   景 Netty 框架的特点 Netty 的一个特点就是入门相对比较容易,但是真正掌握并精通是非常困难的,原因有如下几个: 涉及的知识面比较广:Netty 作为一个高性能的 NIO 通信框架,涉及到的知识点包括网络通信、多线程编程、序列化和反序列化、异步和同步编程模型、SSL/TLS 安全、内存池、HTTP、MQTT 等各种协议栈,这些知识点在 Java 语言中本身就是难点和重点,如果对这些基础知识掌握不扎实,是很难真正掌握好 Netty 的。 调试比较困难:因为大量使用异步编程接口,以及消息处理过程中的各种线程切换,相比于传统同步代码,调试难度比较大。 类继承层次比较深,有些代码很晦涩(例如内存池、Reactor 线程模型等),对于初学者而言,通过阅读代码来掌握 Netty 难度还是比较大的。 代码规模庞大:目前,Netty 的代码规模已经非常庞大,特别是协议栈部分,提供了对 HTTP/2、MQTT、WebSocket、SMTP 等多种协议的支持,相关代码非常多。如果学习方式不当,抓不住重点,全量阅读 Netty 源码,既耗时又很难吃透,很容易半途而废。 资料比较零散,缺乏实践相关的案例:网上各种 Netty 的资料非常多,但是以理论讲解为主,Netty 在各行业中的应用、问题定位技巧以及案例实践方面的资料很少,缺乏系统性的实践总结,也是 Netty 学习的一大痛点。 Please...

[总]消息顺序性为何这么难? 0

[总]消息顺序性为何这么难?

很多业务都需要考虑消息投递的顺序性: 单聊消息投递,保证发送方发送顺序与接收方展现顺序一致 群聊消息投递,保证所有接收方展现顺序一致 充值支付消息,保证同一个用户发起的请求在服务端执行序列一致 消息顺序性是分布式系统架构设计中非常难的问题,有什么常见优化实践呢? Please follow and like us:0

[转]Maven的这三个用法 0

[转]Maven的这三个用法

本文中将介绍maven的自定义插件(入门实战)自定义archeType模板(实战)按环境打包(实战)三个在私服中常常需用的操作。 1、自定义archeType模板的创建 1.1、什么是archeType 我们在创建maven项目的时候,你会发现有这么多的apache提供的模板。 或者使用mvn archetype:generate命令来快速创建maven项目,也会有很多个选项,让你选择模板序号。那每个模板之间有什么区别呢? 每个模板里其实就是附带不同的依赖和插件。一般在公司私服里都会有属于本公司的一套archeType模板,里面有着调试好的项目用到的依赖包和版本号。 1.2、创建archetype 假如自己已经有了一个maven项目,想给该项目创建一个archeType模板。 cd 到项目根目录下执行(pom.xml同级目录)。

此时会在项目target下生成这些文件: 1.3、生成archetype模板 先 cdtarget/generated-sources/archetype/ 然后执行 mvn install 执行成功后,执行crawl命令,在本地仓库的根目录生成archetype-catalog.xml骨架配置文件:

来看一看它里面的内容: 1.4、使用archetype模板 执行mvn archetype:generate -DarchetypeCatalog=local从本地archeType模板中创建项目。

然后会让你选择模板序号和groupIdartifactIdversion和package信息: 项目创建成功! 当然,也可以使用IDEA来帮我们用图形界面使用archeType模板创建项目: 后面的就与创建普通项目相同了,不做演示。 2、自定义插件 在这里我只是做了简单的示例,更复杂的功能开发请参考mojo的API: https://maven.apache.org/developers/mojo-api-specification.html...

[转]Kafka 2.0升级实战!携程的经验有何可借鉴之处 0

[转]Kafka 2.0升级实战!携程的经验有何可借鉴之处

早在 2014 年,携程的一些业务部门开始引入 Kafka 作为业务日志的收集处理系统。2015 年,基于 Kafka 的高并发、大数据的特点,携程框架研发部在 Kafka 之上设计了 Hermes Kafka 消息系统,作为大规模的消息场景的统一的中间件。随着业务量的迅速增加,以及具体业务、系统运维上的一些误用,Kafka 现有系统变得不稳定,经历了多次 down 机,故障期间完全不可用,持续时间长达 5 小时以上,恢复缓慢。Kafka 还能用多久?成为一个迫切棘手的问题。问题严重又难以解决,必须做出改变。 本文主要分享携程将 Kafka 从 0.9 升级到 2.0 的实战经验以及基于 Kafka 2.0 的应用实践。这是 InfoQ 特别策划《Kafka 的七年之痒》专题系列文章的第三篇,前两篇文章回顾见 《Kafka 从 0.7...

[转]网易考拉如何从单体应用走向微服务化 0

[转]网易考拉如何从单体应用走向微服务化

网易考拉(以下简称考拉)是网易旗下以跨境业务为主的综合型电商,自2015年1月9日上线公测后,业务保持了高速增长,这背后离不开其技术团队的支撑。微服务化是电商IT架构演化的必然趋势,网易考拉的服务架构演进也经历了从单体应用走向微服务化的整个过程。 以下整理自网易考拉陶杨在近期Apache Dubbo Meetup上的分享。 Please follow and like us:0

0

[转]深入浅出 Java CMS 学习笔记

引子 带着问题去学习一个东西,才会有目标感,我先把一直以来自己对CMS的一些疑惑罗列了下,希望这篇学习笔记能解决掉这些疑惑,希望也能对你有所帮助。 Please follow and like us:0

[转]业务库负载翻了百倍,我做了什么来拯救MySQL架构? 0

[转]业务库负载翻了百倍,我做了什么来拯救MySQL架构?

最近有一个业务库的负载比往常高了很多,最直观的印象就是原来的负载最高是100%,现在不是翻了几倍或者指数级增长,而是突然翻了100倍,导致业务后端的数据写入剧增,产生了严重的性能阻塞。 一、引入读写分离,优化初见成效 这类问题引起了我的兴趣和好奇心,经过和业务方沟通了解,这个业务是记录回执数据的,简单来说就好比你发送了一条微博,想看看有多少人已读,有多少人留言等。所以这类场景不存在事务,会有数据的密集型写入,会有明确的统计需求。 Please follow and like us:0

[转]如何使用消息队列解决分布式事物 0

[转]如何使用消息队列解决分布式事物

引言 这篇说说分布式事务的问题。企业现在的架构都由传统的架构转向了微服务架构,如下图所示: 那么,都不可避免的会遇到跨数据库调用的,分布式事务问题! 目前,业内解决分布式事务问题,都基本不用JTA这种强一致性的解决方案,基本是采用如下两套方案 基于TCC的事务框架 消息队列 Please follow and like us:0

[转]消息中间件–5消息中间件集群崩溃,如何保证数据不丢失? 0

[转]消息中间件–5消息中间件集群崩溃,如何保证数据不丢失?

“上一篇讲消息中间件的文章《扎心!线上服务宕机时,如何保证数据100%不丢失?》,初步给大家介绍了一个在生产环境中可能遇到的问题,就是你的消费者服务可能会宕机,一旦宕机,你就需要考虑是否会导致没处理完的消息丢失。 这篇文章,再给不太熟悉MQ技术的同学,介绍另外一个生产环境中可能会遇到的问题。 Please follow and like us:0