Category: Java Architecture
![[转]分布式系统Kafka和ES中，JVM内存越大越好吗？](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-medium-empty.png)
[转]一份完整的阿里云 Redis 开发规范
1. 一、键值设计 1-1. 1. key名设计 (1)【建议】: 可读性和可管理性 以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
|
1 |
ugc:video:1 |
(2)【建议】：简洁性 保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：
|
1 |
user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid} |
(3)【强制】：不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符 详细解析
[转]3台廉价机器每秒写入2百万！Kafka为什么那么快？
Kafka 的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间，但是实际上，Kafka 的特性之一就是高吞吐率。
[转]如何使用Redis流和Apache Spark处理实时数据？
1. 本文要点 Apache Spark 的流框架（Structured Streaming）为数据流带来了 SQL 查询功能，让用户可以实时、可扩展地处理数据。 Redis 流（Redis Stream）是 Redis 5.0 新引入的数据结构，能够以亚毫秒级的延迟高速收集、保存和分发数据。 用户集成 Redis 流和流框架后就能简化连续应用程序（continuous application）的扩展工作。 开源的 Spark-Redis 库将 Apache Spark 与 Redis 连接起来。该库为 Redis 数据结构提供 RDD 和数据帧 API，使用户可以将 Redis 流用作流框架的数据源。 流框架是...
[转]消息中间件–5 消息处理失败&死信队列
消息中间件消费到的消息处理失败怎么办？ 一般生产环境中，如果你有丰富的架构设计经验，都会在使用MQ的时候设计两个队列：一个是核心业务队列，一个是死信队列。 核心业务队列，就是比如专门用来让订单系统发送订单消息的，然后另外一个死信队列就是用来处理异常情况的。比如说要是第三方物流系统故障了，此时无法请求，那么仓储系统每次消费到一条订单消息，尝试通知发货和配送，都会遇到对方的接口报错。 此时仓储系统就可以把这条消息拒绝访问，或者标志位处理失败！注意，这个步骤很重要。
mybatis 动态参数及其 foreach collection使用
Mybatis里传参数入Mapper一般基于基本类型，Integer、String、List、Hashtable，然后以此构架foreach迭代动态sql。
|
1 2 3 4 5 6 7 8 |
<select id="findUserListByIdList" parameterType="java.util.ArrayList" resultType="User"> select * from user user <where> user.id in <foreach collection="listName" item="guard" index="index" separator="," open="(" separator="," close=")" > #{guard} </foreach> </where> </select> |
[转]虎牙直播微服务改造实践-Nacos
本文将分为如下几个部分介绍虎牙在 DNS、服务注册、CMDB 和服务配置中心等方面的实践： 为什么选用 Nacos DNS-F 的技术价值和应用场景 服务注册的实践 CMDB 的应用和实践 服务配置的实践 Nacos 改造和升级总结
[汇总]日志开发经验
Spring Boot 服务监控，健康检查，线程信息，JVM堆信息，指标收集，运行情况监控等！ Spring Boot是如何实现日志的？ 阿里巴巴不允许工程师直接使用Log4j和Logback的API！ 3种常见的数据脱敏方案 一个注解搞定接口返回数据脱敏
[汇总]微服务构架经验
1. 最佳实践 微服务架构，多“微”才合适？ 微服务到底该多大？如何设计微服务的粒度？ 如何更好地干掉微服务架构复杂性？ 我大概总结了三个关键词，分别是引入、异构、冗余。 B站在微服务治理中的探索与实践 7个阶段模型，帮助微服务架构落地！ 这里提供了三种策略给大家参考，如图所示： 第一种 Cream Scoop Strategy 冰淇淋勺策略：是 Martin Flower 提出的一种策略，也被称为扼杀者方法。可以想象有一大桶冰淇淋，这桶冰淇淋就代表现有的架构，可以用勺子从桶中挖出你们想要的冰淇淋，这个挖出的部分就是要做拆分的服务。最终可以将大桶冰淇淋挖出一个个独立的服务，这里服务包含不同的业务逻辑。这种方式是逐渐修改原有系统，并且逐步对服务进行拆分试错然后过度到单独的资源上运行。每次拆分对系统的影响较小，但是整个系统的拆分和重构需要较长时间。 第二种 乐高法策略（搭积木），把原有的系统想象成一大块乐高积木，我们只需要往上面添加小的乐高积木模块就行了，添加的小模块就是一个个微服务。这样一来就不用对老产品进行调整，新的功能通过微服务的方式实现并且集成到老的产品中。不过需要通过一种能够让微服务与老产品联系的方法，这里会使用到接口编程以及适配器模式。 第三种是 nuclear 策略，和策略的名字一样我们需要对老旧系统推到重来，重新打造微服务架构，说起来容易这里需要花费大量分析和重构的时间，这个周期比较长，成本也是较高的。
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
