zhifeng687-CSDN博客

转载金融风控领域的 DDD 与中台思考

风控领域作为金融核心领域之一，对金融业务发展有着至关重要的作用。风控直译就是风险控制，其核心是对风险与成本的平衡。风控业务开展离不开风控系统的支持，本文就风控系统如何规划架构与演进，以及对领域驱动设计的思想和风控中台战略的思考。风控与 DDD领域驱动设计（DDD）作为微服务拆分的指导思想随着微服务化火起来，但其过于抽象难懂，网上方法论众多，而案例较少。本文尝试对风控领域如何按 DDD 思想设计给出一些实践和思考。DDD 从需求分析出发进行领域建模，先划分出多个问题域和子域，再将问题域落实到限

2022-05-01 23:00:31 3400

转载智能风控决策引擎系统架构设计与开发实践

I.内容提要前几天做客“技术琐话”直播间进行分享，本文根据分享内容整理出来。内容主要包括：风控决策引擎系统从架构设计到开发实践特征引擎系统及实时计算引擎模型引擎系统及智能风控引擎大数据风控-用数据驱动的风控全流程系统构建 II.风控决策引擎介绍Q：互金领域的风险有哪些？A：欺诈风险、信用风险、合规风险（监管要求）Q：如何对抗风险？A：通过大数据来构建规则和模型进行风险控制和风险预警Q：业务规则和模型策略如何落地？A：通过决策引

2022-05-01 22:55:42 4413

转载慢sql熔断方案--饿了么数据库中间件DAL

代理层(DAL)，最直观的需求是能做分库分表，能做读写分离，还可以做资源隔离、连接数隔离、连接的管理等，更重要的是还能对数据库进行相应的保护。外卖业务大多数人都是在中午下单，所以 11 点左右是饿了么的业务高峰。为了缓解数据库压力，我们会通过 DAL 层做削峰处理，当流量过大时我们会让用户消息做排队的处理，由此缓解对数据库的瞬间冲击。如果流量特别大的时候还可以做限流、熔断等处理。还有黑白名单机制，大家了解数据库运维的话会知道，如果研发写的 SQL 有问题，放入到数据库里风险会比较高。如果..

2022-04-20 20:10:27 864

转载慢sql熔断方案--美团的数据库中间件DBProxy

概述首先介绍一下为什么要使用DBProxy:使用DBProxy之后，应用程序只需要在连接串中设置DBProxy的地址，不需要关注整个数据库集群的结点； DBProxy内部实现负载均衡，读写分离； Slave上下线的操作由DBA在自动化运营系统上点一下鼠标就能够完成。这样极大的减轻了DBA和应用开发人员的工作；而没有DBProxy的情况下，这些工作是由RD来实现的，引入DBProxy对于系统的可管理性和便利性都有非常大的帮助。DBProxy的主要功能介绍DBProxy的软件模...

2022-04-20 20:00:27 602

转载异地多活的架构演进

在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。有幸，我曾经深度参与过一个中等互联网公司，建设异地多活系统的设计与实施过程。所以今天，我就来和你聊一聊异地多活背后的的实现原理。认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。这篇文章干货很多，希望你可以耐心读完。01

2022-04-17 15:05:36 323

原创处理redis热key的流程思维导图

LFU缓存机制LFU（Least Frequently Used）算法，即最少访问算法，根据访问缓存的历史频率来淘汰数据，核心思想是“如果数据在过去一段时间被访问的次数很少，那么将来被访问的概率也会很低。实现class LFUCache { // 缓存容量，时间戳 int capacity, time; Map<Integer, Node> key_table; TreeSet<Node> S; public LFUCa...

2022-04-10 00:59:22 2847

转载饿了么解决redis热key的业务实践

背景在 Redis 中，热 key 指的是那些在一段时间内访问频次比较高的键值，具体到业务上，商品的限时抢购、瞬时的新闻热点或某个全局性的资源，都极有可能产生热点 key。热点 key 的出现可能会对系统的稳定性和可用性造成影响，比如对应节点的网卡带宽被打满，出现丢包重传，请求波动耗时大幅上升，甚至影响到业务的正常使用，引发用户的不满。因此，在日常的工作中，我们需要着重避免这种情况的出现，比如在设计和编码阶段避免引入全局性热 key，或者在设计时考虑热 key 出现时的应对方案。可能的方案热

2022-04-09 23:20:49 252

转载缓存热点自动发现和处理的架构设计实践

一、为什么要用缓存集群啥叫热 Key 和大 Value 呢?简单来说，热 Key，就是你的缓存集群中的某个 Key 瞬间被数万甚至十万的并发请求打爆。大 Value，就是你的某个 Key 对应的 Value 可能有 GB 级的大小，导致查询 Value 的时候出现网络相关的故障问题。先来看看下面的一幅图：简单来说，假设你手头有个系统，他本身是集群部署的，然后后面有一套缓存集群，这个集群不管你用 Redis Cluster，还是 Memcached，或者是公司自研缓存集群，都可以。那么

2022-04-09 20:25:50 364

转载京东毫秒级热key探测框架设计与实践

在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户，这些突发的无法预先感知的热key都是系统潜在的巨大风险。风险是什么呢？主要是数据层，其次是服务层。热key对数据层的冲击显而易见，譬如数据存放在redis或者MySQL中，以redis为例，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都从该分片获取它的数据。由于redis性能还不错，再加上集群模式，每秒我们

2022-04-09 19:57:09 456

转载直播系统解决高并发下缓存热key的业务实践

直播是人类智慧的极佳体现，通过技术将模拟数据数字化，打破自然界光线和声音传播的刚性约束，实现隔空重放，让信息摆脱物理学的约束低成本传播，并自然地实现价值放大。在手机 APP、浏览器等终端上，我们可以通过一个个窗口，便捷地看到那些隔空重放的信息，或一个鲜活的人或一场热闹的戏或一堆精美的物品，商业上的人、场、” 货 “都能在这个虚拟的载体上呈现。这个载体我们一般称为直播间，或者叫房间。也引出不少耳熟的词汇，如进房间、出房间、开启房间等等。直播的场景天然以人为核心，场由人造，“货” 因人而存在，可以是

2022-04-09 18:48:22 339

转载评论系统架构设计

架构设计最重要的就是理解整个产品体系在系统中的定位。搞清楚系统背后的背景，才能做出最佳的设计和抽象。不要做需求的翻译机，先理解业务背后的本质，事情的初衷。功能模块评论系统，我们往小里做就是视频评论系统，往大里做就是评论平台，可以接入各种业务形态。发布评论: 支持回复楼层、楼中楼。读取评论: 按照时间、热度排序。删除评论: 用户删除、作者删除。管理评论: 作者置顶、后台运营管理(搜索、删除、审核等)。架构设计概览 BFF: comment 复杂评论业务的服务编排，比如访问

2022-04-09 12:15:19 3056 4

原创 https握手原理思维导图

参考：SSL / TLS 工作原理和详细握手过程HTTPS 工作原理详解 | TLS握手过程

2022-04-07 23:00:15 219

转载 Https工作原理＆TLS握手机制

HTTPS 概念HTTPS 就是一个有安全保障的 HTTP 通信，我们都知道，http 是明文传输的，http 报文是人肉眼就可识别的 ASCII 码，在通信过程中，http 报文很容易被黑客窃听、篡改、伪造，而在互联网交易中，我们必须保证通信安全，所以就需要像 https 这样有安全层的协议。那么，https是怎么保障通信安全的呢？什么样的通信可以被称为是安全的，安全的定义是什么？通常，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。而HT

2022-04-07 22:14:05 908

转载 Redis持久化之RDB原理

一、为什么需要持久化redis里有10gb数据，突然停电或者意外宕机了，再启动的时候10gb都没了？！所以需要持久化，宕机后再通过持久化文件将数据恢复。二、优缺点1、rdb文件rdb文件都是二进制，很小。比如内存数据有10gb，rdb文件可能就1gb，只是举例。2、优点由于rdb文件都是二进制文件，所以很小，在灾难恢复的时候会快些。他的效率（主进程处理命令的效率，而不是持久化的效率）相对于aof要高（bgsave而不是save），因为每来个请求他都不会处理任何事，只是bgsave的时候他会

2022-04-07 21:31:04 1515

原创一致性哈希思维导图

参考：理解一致性哈希算法

2022-04-07 21:00:16 216

转载大量数据去重：Bitmap和布隆过滤器(Bloom Filter)

在面试时遇到的问题，问题的解决方案十分典型，但对于海量数据处理接触少的同学可能一时也想不到什么好方案。介绍两个算法，对于空间的利用到达了一种极致，那就是Bitmap和布隆过滤器(Bloom Filter)。Bitmap算法在网上并没有找到Bitmap算法的中文翻译，在《编程珠玑》中有提及。与其说是算法，不如说是一种紧凑的数据存储结构。其实如果并非如此大量的数据，有很多排重方案可以使用，典型的就是哈希表。public int[] removeDuplicates(int[] array) { ..

2022-04-07 20:24:44 1894

转载 BitMap的JAVA实现

相关概念基础类型在java中： byte -> 8 bits -->1字节char -> 16 bit -->2字节short -> 16 bits -->2字节int -> 32 bits -->4字节float -> 32 bits -->4字节long -> 64 bits -->8字节位运算符在java中，int数据底层以补码形式存储。int

2022-04-07 19:31:37 2803 1

转载旧版苹果退款通知

1、前言今年 WWDC 2020 苹果全球开发者大会，苹果宣布所有的内购品项类型，当用户退款成功时，开发者都能收到退款通知！！！退款通知！！！退款通知！！！针对 App 内购买项目的退款通知现已可用2020 年 06 月 24 日 App Store 服务器通知现在包含所有类型的 App 内购买项目的退款通知 (包括消耗型项目、非消耗型项目和非续期订阅)。这些信息能帮助您采取相应的行动，并告知他们相关的优惠更改，以及如何重新订阅。针对 App 内购买项目的退款通知现已可用 - 新闻 - A

2022-04-04 20:29:09 3648 1

转载 V1版本苹果通知

接收解析v1版本苹果通知（订阅，退款）基本步骤1.苹果后台创建订阅商品，创建共享密钥password2.苹果后台配置通知自己服务器地址url3.解析苹果通知，开发自己的逻辑（主要编程部分）1.苹果后台创建订阅商品苹果后台创建商品列表的上方，就会有创建共享密钥的按钮，只有拥有该权限的人才能看到，重点来了，创建了共享密钥，在验证苹果收据的时候所有的商品都要增加参数，把收据和共享密钥都要发到苹果服务器进行验证，共享密钥作用于所有商品。进入苹果后台-管理-创建共享密钥，后台地址 https:/

2022-04-04 19:19:07 949

原创 Netty模型架构和思维导图

Reactor多线程模型--连接与I/O操作分离若请求连接的并发量是数以百万计的，且 IO 操作还比较耗时，此时的 Server 即使采用的是 Reactor 线程池模型，系统性能也会急剧下降。此时，可以将连接操作与 IO 操作分开处理，形成 Reactor 的多线程模型。当客户端通过处理连接请求的 Channel 连接上 Server 后，系统会为该客户端再生成一个子 Channel 专门用于处理该客户端的 IO 请求。这两类不同的 Channel 连接着两类不同的线程池。而线程池中的线程..

2022-04-01 19:26:36 836

原创 JVM知识思维导图

参考：Full GC触发条件总结从实际案例聊聊Java应用的GC优化 - 美团技术团队JVM系列之STW、并行与并发、安全点与安全区域G1总结G1垃圾收集器介绍

2022-03-31 00:45:19 355

原创设计模式思维导图

参考：设计模式

2022-03-30 18:00:32 316

原创 Spring Bean生命周期思维导图

参考：Spring Bean 的生命周期

2022-03-30 00:48:08 338

原创 Spring IOC执行流程思维导图

IOC执行流程图执行流程的各个步骤

2022-03-30 00:41:55 954

转载基于死信队列实现RabbitMQ消息消费失败后的处理方案

死信队列的使用：处理失败的消息一般生产环境中，如果你有丰富的架构设计经验，都会在使用MQ的时候设计两个队列：一个是核心业务队列，一个是死信队列。核心业务队列，就是比如上面专门用来让订单系统发送订单消息的，然后另外一个死信队列就是用来处理异常情况的。之所以我们这篇文章抛出一个面试题，结果先长篇大论说一个生产实践案例和业务场景，就是因为面试被问到这个问题时，必须要结合你自己的业务实践经验来说。你需要先给面试官说有血有肉的业务系统场景，然后再结合这个场景回答他的问题，因为面试官想听的就是你

2022-03-29 01:12:45 1471

转载 RabbitMQ 消息确认机制、补偿机制、消息幂等性实践

1. 场景先看这么几个面试题：如何保证消息的可靠性投递？即如何确定消息是否发送成功？如果失败如何处理（补偿机制）？如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？2.消息的可靠性投递消息确认消息确认包括主要生产者发送确认和消费者接收确认，因为发送消息的过程中我们是无法确认消息是否能路由等，一旦消息丢失我们就无法处理，所以需要确认消息，避免消息丢失。2.1 生产者确认我们知道生产者与消费者完全隔离的，不做任何配置的情况下，生产者是不知道消息是否真正到达...

2022-03-29 01:10:03 581

转载 RabbitMq和kafka在可靠性、吞吐量等的区别

kafka介绍kafka是apache开源的消息队列顶级项目之一，在大数据场景下使用较多，由linkedin开源，目前社区活跃，全球较多组织开始使用kafka来进行数据交换。rabbitmq介绍RabbitMQ是流行的开源消息队列系统，用erlang语言开发。RabbitMQ是AMQP（高级消息队列协议）的标准实现。kafka和rabbitmq全面对比分析实际场景选择在实际生产应用中，通常会使用kafka作为消息传输的数据管道，rabbitmq作为交易

2022-03-29 01:06:17 1877

转载 kafka实现消息高可靠性的机制

消息可靠性维度消息的可靠性性一般需要从三个维度进行考量。分别是生产端、服务端、消费端。发送端可靠性：生产者需要确保消费发送到了服务端机器上。服务端存储可靠性：服务端需要保证消息的持久化不丢失。消费可靠性：消费端需要确认每条消息都被成功进行消费。producer可靠性对于kafka生产端来说，发送消息主要有两类API可以调用，分别是producer.send(msg)和producer.send(msg，callback)。producer.send(msg)：俗称“发后即忘”，不

2022-03-29 01:02:57 690

转载消息中间件选型分析：从 Kafka 与 RabbitMQ 的对比看全局

一、前言消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如 ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ 等。不管选择其中的哪一款，都会有用的不

2022-03-29 00:53:24 242

转载 RabbitMQ消息消费失败后的处理方案

Q：业务系统之间通过MQ进行交互，当消费者发生未知异常时，消息消费失败，如何处理才保证消息的消费的可靠性。 A：从如下几点考虑何时ack 无论消息成功还是失败，都会ack，消息不会堆积在MQ中只有成功才ack，消息堆积在MQ中消费日志接收消息后先入库入库失败，直接开始重试入库成功，开始后续业务逻辑 ..

2022-03-29 00:36:18 5356

转载 rabbitMQ和rocketMQ的消息可靠性机制

在我们大多数场景中，MQ消息都要保证可靠性，消息可靠性应该是我们最关心的一个细节，没有之一；而各个MQ实现的可靠性保证都不同，同时实现机制也不同，只有知道各个MQ实现是如何保证消息可靠性的，才能在使用的过程中不丢消息；rabbitMQ对于rabbitMQ，消息可靠性是从以下几点来保证的：消息持久化；发布者确认；消费者确认；消息持久化对于rabbitMQ，默认情况下消息是不持久化的，这是为了性能考虑，但是这样会导致消息在服务器重启后丢失，这在我们大多数场景下都是不可接受的，所以，我们

2022-03-28 23:21:54 561

转载 RabbitMq实现消息高可靠性机制

1. 📖如何保证消息的可靠性？先来看看我们的万年老图，从图上我们大概可以看出来一个消息会经历四个节点，只有保证这四个节点的可靠性才能保证整个系统的可靠性。生产者发出后保证到达了MQ。 MQ收到消息保证分发到了消息对应的Exchange。 Exchange分发消息入队之后保证消息的持久性。消费者收到消息之后保证消息的正确消费。经历了这四个保证，我们才能保证消息的可靠性，从而保证消息不会丢失。2. 🔍生产者发送消息到MQ失败我们的生产者发送消息之后可能由于网络闪断等各种原因导致我们

2022-03-28 23:14:13 259

转载 Spring-RabbitMQ-自动补偿机制

1. 自动补偿机制在RabbitMQ里，如果消费者在处理消息时，业务逻辑出现异常，默认会执行补偿机制（也就是消息重试机制）。如果业务逻辑出现异常，是不会消费消息的。基于上一篇博客的例子《消息中间件系列教程（13） -RabbitMQ-SpringBoot集成RabbitMQ》来演示一下。现在消费者处理消息的地方模拟一个异常：生产者发送消息给消费者，会发现控制台一直在打印错误日志，也就是说，消费者一直在重试消费（补偿）：也可以在RabbitMQ控制台看到，消息时没有被消费的..

2022-03-28 23:04:00 643

转载雪花算法解决时钟回拨问题

SnowFlake算法据国家大气研究中心的查尔斯·奈特称，一般的雪花大约由10^19个水分子组成。在雪花形成过程中，会形成不同的结构分支，所以说大自然中不存在两片完全一样的雪花，每一片雪花都拥有自己漂亮独特的形状。雪花算法表示生成的id如雪花般独一无二。snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每

2022-03-23 16:20:03 11844 3

TA关注的人

ios的网络图片下载类库

viewpager的下横线指示器

viewpager实现页面导航之三

viewpager实现页面导航

viewpager与预编译的点布局实现页面导航效果

进销存管理系统之二

进销存管理系统

java+Mysql学生数据库管理系统

MyListView

导入第三方类库却出现the importXXX can not be resolved