- 博客(631)
- 资源 (7)
- 收藏
- 关注
RSS订阅
转载 DDD（领域驱动设计）
基本概念： 领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书。，书中提出了“领域驱动设计(简称 ddd)”的概念。 领域驱动设...
2019-07-08 15:25:45
267406
33
转载 ES模糊查询wildcard的替代方案
例如：min_gram，max_gram配置为5时，quick.brown.fox分词后会产生quick，uick.，ick.b，ck.br，k.bro，.brow，brown，rown.，own.f，wn.fo，n.fox。b.用户输入brown.fox，brown.fox会被分词成brown，rown.，own.f等，此时同样会返回quick.brown.fox。例如quick将会被分词为q，u，i，…a.用户输入quick，brown，k.bro等都能够返回quick.brown.fox。
2024-03-21 21:41:38
222
转载 什么是大模型？一文读懂大模型的基本概念
引申到模型层面，涌现能力指的是当模型的训练数据突破一定规模，模型突然涌现出之前小模型所没有的、意料之外的、能够综合分析和解决更深层次问题的复杂能力和特性，展现出类似人类的思维和智能。在探索期，以 Transformer 为代表的全新神经网络架构，奠定了大模型的算法架构基础，使大模型技术的性能得到了显著提升。而当模型的训练数据和参数不断扩大，直到达到一定的临界规模后，其表现出了一些未能预测的、更复杂的能力和特性，模型能够从原始训练数据中自动学习并发现新的、更高层次的特征和模式，这种能力被称为“
2024-03-14 21:18:07
267
转载 高德打车稳定性建设
高德打车是高德地图首创的“聚合打车”模式，一键全网叫车，轻松全网比价，让用户打车更快、更省；推出“好的出租”计划，帮助传统巡游出租车数字化升级，帮助出租车司机增加收入。高德打车在运力类型上有网约车、出租车、巡改网、城际拼车等；同时订单类型又有实时单、预约单、代叫单、接送机、市内拼车等；当然在车型和价格上也有一定区分。
2024-03-08 22:15:00
100
转载 滴滴业务中台构建实践
滴滴是一家以出行为核心、辐射单车、代驾、车服、金融、国际化等领域的高速发展的科技公司，在各条业务线飞速发展的过程中会存在着很多相同或者类似的业务需求，如何通过技术的手段抽象、沉淀这些业务为通用、稳定基础能力，让各业务线专注于其个性化的部分，快速的推出适合市场的新产品，是业务中台核心价值的体现。滴滴业务中台已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力，高效率、低成本的支持了各条业务线的快速发展。何修峰，就职于滴滴业务中台，任高级技术专家一职，致力于。
2024-02-22 21:01:51
72
转载 美菜网交易中台建设
云杉是中国最大的 ToB 生鲜电商美菜网的公司主体，云杉下包括美菜在内的各业务线的急速扩张和更深入的精细化运营，带来了更高的业务复杂度，之前的系统架构已经很难支撑目前多业务多平台的形态，部门的效率也因为系统耦合而大大下降。在业务发展的过程中遇到很多问题，不断的对业务流程和系统架构进行思考，尝试以中台化思维解决问题，并借着2018年底新电商业务线成立之时，推动公司建立中台团队，目前主要负责商品中心和交易中心的架构工作。对电商及周边体系的关系有一个更清晰的认识。对电商交易核心的理解，抓住问题的本质。
2024-02-22 20:59:47
55
转载 Salesforce元数据驱动的多租户架构原理
Salesforce可能是这个世界上最有名的To B领域的公司，市值2500亿美元，凭借着SaaS化的架构理念，并通过依此构建的CRM产品占据CRM 20%的市场，财富500强的公司中，有83%在使用它。公司雇员超过5万人，其业务范围包括财税管理软件、人力资源管理软件、进销存管理软件、客户管理软件、办公自动化软件、企业内即时交流软件等。1999年，Salesforce在美国旧金山成立2001年，推出第一款SaaS应用CRM，同时也受到众多厂商和客户的热议。
2024-02-22 20:51:13
90
转载 物流的盈利模式是什么？
中国物流发展到今天，信息化是重要的工具，但物流行业企业间的业务差异化太大，没一家物流软件能够成为行业标准，就连同一个企业面临不同的客户，产品的差异化也巨大，所以说那些把物流软件产品化其实是一件非常困难的事，唯一可能的是软件模块产品化，PASS平台化的服务可能是这种模式的终极。你的站点布局越多，你的盈利就越多。国内几家物流信息化服务商，已经在创新的推出SAAS或类似SAAS的服务平台，在物流IT服务上提供创新的服务的企业，各有各的特色，他们的共同点都是开放的运营平台服务模式，通过用户数来收费。
2023-11-28 21:48:39
950
转载 阿里云大故障后问责机制来了
不过我作为管理者，对我团队做稳定性的同学，始终坚持自己的理念，充分看见这件事背后的辛苦，对他们只会做奖励上的倾斜，相反一些非低级问题导致的故障却不会追责。出一次大故障，从上到下开始各种复盘，纠错，定责，然后再起稳定性战役，领导们以为和营收战役一样，战役包治百病，只要战役一结束，目标达成，这个事情也就成功了结束了。除了有大流量高并发经验的技术同学外，其他人很难理解：稳定性是一个长期持久的事情，只要流量在上涨，客户在增加，业务在丰富，那么稳定性的事情就不会中断。优先提升稳定性意识，做好变更管控、流程规范；
2023-11-24 20:10:49
182
转载 从阿里云大故障看稳定性
其实这是最重要的却常常被忽略，栽一棵树最好的时间是十年前，然后是现在，三年后平台的高可用做到什么级别取决于当下上层OKR对它的定位，最容易出现超大故障的时候，常常是自上而下业务非常自嗨的时候，有些高层甚至可能都瞧不起被他们类比成水泥匠的稳定性打工人，认为做好稳定性是应该的，做不好就得挨板子，在这种人浮于事的环境下，要把稳定性坚持做好，需要底下管理者和团队非常强的责任心和使命感，但永远不要忽略人性，再强的责任心也需要现实激励去喂养。故障越大，锅就越不是执行变革的一线同学的，为什么呢？
2023-11-24 20:08:56
144
转载 毕玄：稳定性，难的不是技术，而是……
只有把稳定性当成业务的功能实现一样，有相应的人员配备和投入，例如做一个业务可能需要多少人，相应的稳定性这块也固定投入多少人，你说到底多少比例合理呢，其实也说不太清楚，但这种简单粗暴的方式其实是最有效的，当然，是不是要把稳定性上升到这样的高度，也需要根据业务的性质、业务所处的阶段来具体判断，以及有这样的投入的情况下，怎么去评判相应职责的团队也仍然是个很复杂的话题。很多做过稳定性这事的人都知道，做这个事情最麻烦的是很难被认可，做的好，不出问题，不懂的人不知道你做了什么，出了问题的时候觉得你到底做了什么，
2023-11-15 21:15:00
94
原创 ES索引重建reindex详解
ES分片数变更、mapping字段变更、分词规则修改等必须重建索引，此时可通过es本身自带的reindex功能进行数据迁移，支持跨索引、跨集群的数据迁移。
2023-08-09 22:30:00
3166
1
转载 一文搞懂Redis架构演化之路
总结一下，我们是如何从 0 到 1，再从 1 到 N 构建一个稳定、高性能的 Redis 集群的，从这之中你可以清晰地看到 Redis 架构演进的整个过程。数据怕丢失：持久化（RDB/AOF）主从副本（副本随时可切）故障手动切换慢：哨兵集群（自动切换）读存在压力：扩容副本（读写分离）写存在压力/容量瓶颈：分片集群分片集群社区方案：Twemproxy、Codis（Redis 节点之间无通信，需要部署哨兵，可横向扩容）分片集群官方方案。
2023-07-25 22:01:11
117
转载 搞懂异地多活，看这篇就够了
好了，总结一下这篇文章的重点。1、一个好的软件架构，应该遵循高性能、高可用、易扩展 3 大原则，其中「高可用」在系统规模变得越来越大时，变得尤为重要2、系统发生故障并不可怕，能以「最快」的速度恢复，才是高可用追求的目标，异地多活是实现高可用的有效手段3、提升高可用的核心是「冗余」，备份、主从副本、同城灾备、同城双活、两地三中心、异地双活，异地多活都是在做冗余4、同城灾备分为「冷备」和「热备」，冷备只备份数据，不提供服务，热备实时同步数据，并做好随时切换的准备。
2023-07-25 21:58:18
904
转载 ElasticSearch的segment段合并原理
如果某次合并产生的索引段的大小大于index.merge.policy.max_merged_segment参数值，则该合并策略会选择更少的索引段参与合并，使得生成的索引段的大小小于阈值。比如日志的场景下，日志基本都是按天，周，或者月来索引的，旧索引实质上是只读的，只要过了今天、这周或这个月就基本没有写入操作了，这个时候我们就可以通过 optimize 命令，来强制合并每个shard上索引只有一个segment，这样既可以节省资源，也可以大大提升查询性能。否则启动跟 CPU 核数的一半相等的线程数。
2023-07-25 21:51:39
399
转载 京东 App 秒级百 G 日志传输存储架构设计与实战
我们可以简单的做一些对比，主要在于硬件成本和软件性能的对比。从上文可知，磁盘的占用原始方案占用了磁盘（1 份），MQ（2 份），数据库（1 份）。而在新的方案中，磁盘的占用仅剩下 clickhouse 的（0.8 份），clickhouse 自身又对数据做了压缩，实际占用空间不到入库容量的 80%。那么仅磁盘即可节省 75% 以上的存储成本。大家都知道，秒级的吞吐量，是伴随着服务器 Cpu 的耗费的，并不是说只给个大硬盘，即可一台服务器每秒吞吐 1 个 G 的。
2023-07-25 21:44:20
159
转载 【Flink SQL】大家都用 cumulate window 计算累计指标啦
如官网文档所示，介绍 cumulate window 的第一句话就是 cumulate window 非常适合于之前使用 tumble window + early-fire 的场景。可以说 cumulate window 就是在用户计算周期内累计 PV，UV 指标时，使用了 tumble window + early-fire 后发现这种方案存在了很多坑的情况下，而诞生的！
2023-04-12 22:18:42
2076
3
转载 [白话解析] Flink的Watermark机制
对于Flink来说，Watermark是个很难绕过去的概念。本文将从整体的思路上来说，运用感性直觉的思考来帮大家梳理Watermark概念。
2023-04-12 21:59:25
561
转载 谁是 JDK8 中最快的 GC
我们都知道 OpenJDK8 有好几个垃圾回收算法，比如 ParallelGC，CMS，还有 G1，那么哪个才是最快的？如果 GC 算法从 Java8 中默认的 ParallelGC 切换到 G1 会发生什么（JDK9 就是把默认 GC 从 ParallelGC 切到了 G1）？
2023-04-12 21:53:04
640
转载 通用流程编排组件JDEasyFlow介绍
JDEasyFlow是京东企业金融研发部自研的通用流程编排技术组件，适用于服务编排、工作流、审批流等场景，该组件已开源(https://github.com/JDEasyFlow/jd-easyflow)，目前在部门的内部业务系统和科技输出系统中广泛应用，其他部门也有使用。
2023-04-12 21:33:45
771
原创 ES高级操作手册
当ES扩容缩容时，若分片太大，分片初始化会很慢，此时可选择修改ES配置加快recovery速度。若是生产环境ES在对外提供服务，es默认配置可能导致对外服务抖动，也可以通过修改配置降低recovery速度。es默认限制了并行恢复的数量，速度等。
2022-10-22 19:45:00
1897
转载 分布式系统的SLA如何定义
SLA（Service-Level Agreement）服务等级协议，是指系统服务提供者（Provider）对客户（Customer）的一个可量化的服务承诺，常见于大型分布式系统中，用于衡量系统服务是否稳定健康的常见方法。
2022-10-18 20:15:00
1841
转载 99.999%，提升ElasticSearch稳定性的秘密
ElasticSearch 是一个分布式的开源搜索和分析引擎，因其功能强大、简单易用而被应用到很多业务场景。在生产环境使用 ES 时，如果未进行优化则服务的稳定性可能得不到保障，目前我们使用 ES 作为账单平台的基础组件为微信支付提供服务时就遇到这种问题。本文即从当前的业务场景出发，分析 ES 稳定性未到达要求的原因并提供相应的解决思路。
2022-10-11 20:00:00
294
转载 Elasticsearch 在地理信息空间索引的探索和演进
LBS服务是当前互联网重要的一环，涉及餐饮、娱乐、打车、零售等场景。在这些场景中，有很重要的一项基础能力：搜索附近的POI。比如搜索附近的美食，搜索附近的电影院，搜索附近的专车，搜索附近的门店。
2022-10-11 19:45:00
435
转载 TiDB最佳实践
数据库是一个通用的基础组件，在开发过程中会考虑到多种目标场景，在具体的业务场景中，需要根据业务的实际情况对数据的参数或者使用方式进行调整。TiDB 是一个兼容 MySQL 协议和语法的分布式数据库，但是由于其内部实现，特别是支持分布式存储以及分布式事务，使得一些使用方法和 MySQL 有所区别。
2022-09-30 21:30:00
529
转载 三篇文章了解 TiDB 技术内幕 - 谈调度（三）
整个系统是在动态变化，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进，如果没有一个掌握全局信息，可以对全局进行调度，并且可以配置的组件，就很难满足这些需求。因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。
2022-09-30 21:00:00
201
转载 三篇文章了解 TiDB 技术内幕 - 说存储（一）
很多人用过数据库，但是很少有人实现过一个数据库，特别是实现一个分布式数据库。了解数据库的实现原理和细节，一方面可以提高个人技术，对构建其他系统有帮助，另一方面也有利于用好数据库。
2022-09-30 20:30:00
251
转载 海量 Region 集群调优最佳实践
在 TiDB 的架构中，所有数据以一定 key range 被切分成若干 Region 分布在多个 TiKV 实例上。随着数据的写入，一个集群中会产生上百万个甚至千万个 Region。单个 TiKV 实例上产生过多的 Region 会给集群带来较大的负担，影响整个集群的性能表现。本文将介绍 TiKV 核心模块 Raftstore 的工作流程，海量 Region 导致性能问题的原因，以及优化性能的方法。
2022-09-29 22:00:00
187
转载 TiDB 高并发写入场景最佳实践
在 TiDB 的使用过程中，一个典型场景是高并发批量写入数据到 TiDB。本文阐述了该场景中的常见问题，旨在给出一个业务的最佳实践，帮助读者避免因使用 TiDB 不当而影响业务开发。
2022-09-29 21:45:00
489
转载 TiDB 热点问题处理
TiDB 作为分布式数据库，内建负载均衡机制，尽可能将业务负载均匀地分布到不同计算或存储节点上，更好地利用上整体系统资源。然而，机制不是万能的，在一些场景下仍会有部分业务负载不能被很好地分散，影响性能，形成单点的过高负载，也称为热点。TiDB 提供了完整的方案用于排查、解决或规避这类热点。通过均衡负载热点，可以提升整体性能，包括提高 QPS 和降低延迟等。
2022-09-29 21:30:00
267
转载 Raft协议是如何实现数据一致性的
Raft协议是一种强一致性、去中心化、高可用的分布式协议，它是用来解决分布式一致性问题的，相对于大名鼎鼎的Paxos协议，Raft协议更容易理解，并且在性能、可靠性、可用性方面是不输于Paxos协议的。许多中间件都是利用Raft协议来保证分布式一致性的，例如Redis的sentinel，CP模式的Nacos的leader选举都是通过Raft协议来实现的。今天就和大家一起探讨一下Raft协议的实现原理。
2022-09-29 18:38:06
1592
转载 数据分析的价值
本文结合作者自己多年数据分析的经验和理解，来谈谈数据分析的价值，希望给从事数据分析工作或者对数据分析感兴趣的读者提供一个思考数据分析价值的框架，更好地帮助大家利用好数据分析这个强有力的工具，最终让数据分析产生业务价值，利用数据来驱动业务发展。
2022-09-22 20:34:37
449
转载 支持频繁更新、即席查询：ClickHouse 在爱奇艺视频生产的应用
众所周知，爱奇艺拥有海量视频，在视频生产过程中产生的上千 QPS 的实时数据、T 级别的数据存储。要支持这样的数据进行即席查询和多个大表的 JOIN，是爱奇艺视频生产团队大数据应用的难点。
2022-09-13 19:59:59
340
修复版ajaxfileupload
2017-08-09
tomcat+redis实现session共享
2015-12-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人