- 综合排序
- 最热优先
- 最新优先
- 来自专栏机器学习与推荐算法
推荐系统实践系列 | 一、推荐系统流程设计
推荐系统主要解决的是信息过载问题，目标是从海量物品筛选出不同用户各自喜欢的物品，从而为每个用户提供个性化的推荐。 推荐系统往往架设在大规模的业务系统之上，不仅面临着用户的不断增长，物品的不断变化，而且有着全面的推荐评价指标和严格的性能要求（Netflix 的请求时间在 250 ms 以内，今日头条的请求时间在 200ms 为了解决如上这些问题，推荐系统通常被设计为三个阶段：召回、排序和调整，如下图所示： ? 这里以文章推荐系统为例，讲述一下推荐系统的完整流程，如下图所示： ? 同步业务数据 为了避免推荐系统的数据读写、计算等对应用产生影响，我们首先要将业务数据从应用数据库 MySQL 同步到推荐系统数据库 Hive 中，这里利用 Sqoop 先将 MySQL 中的业务数据同步到推荐系统的
2.6K33发布于 2020-04-20 - 来自专栏全栈技术
边缘计算系统设计与实践
本文将对边缘计算系统的设计与实践进行详细的介绍。一、边缘计算概述边缘计算是一种分布式计算模式，它将计算任务从云端迁移到网络边缘，使得数据处理更加高效、灵活和安全。 三、边缘计算系统设计设计一个边缘计算系统需要考虑以下几个方面：节点选择：选择合适的边缘节点是边缘计算系统设计的关键。节点的选择需要根据实际需求和场景来确定，如数据量、处理能力、网络环境等。 四、边缘计算系统实践下面通过一个简单的例子来说明如何实现一个基于Python的边缘计算系统。这个例子中，我们将实现一个简单的图像处理应用，该应用可以在边缘节点上对图像进行预处理和压缩。 总结本文对边缘计算系统的设计与实践进行了详细的介绍。 通过对边缘计算系统的设计原则和方法的介绍，以及对一个简单图像处理应用的实践，我们可以看到，边缘计算具有高效、灵活和安全的特点，能够为物联网、大数据和人工智能等领域提供强大的支持。
87511编辑于 2023-11-22 - 来自专栏肉眼品世界
智能风控系统设计与实践
本文以智能风控在线特征系统为原型，重点从线上数据从生产到特征物料提取、计算、存取角度介绍一些实践中的通用技术点，以解决在线特征系统在高并发情形下面临的问题和挑战。 特征系统的基本概念 1. 在线实时特征系统设计与实践，对从整体功能上来讲，在线实时特征系统的设计主要考虑以下几个方面： a) 数据大，风控系统每天产生日志量3TB左右，同时特征系统还会接入发布、浏览、登录、注册、聊天等数据。 下文主要围绕特征系统的核心功能在开发过程中遇到的问题及解决办法和一些通用的实践经验等展开介绍，如数据字典建设、分布式系统设计、在线特征计算框架、低延迟计算等主题会在下面文章中做详细介绍。 1. 如果有一个特征查询时间点是10:10，那么我们当前系统只存储了10:00的特征值，10:15特征值还没有计算出来。因此对时间特别敏感的特征应该采用TC的方式计算，图8为TC设计的核心流程。 ? 总结和规划 本文主要以智能风控在线特征系统为原型，提出了在线特征系统的一些设计思路。其中特征工程系统的边界并不限于特征的解析、计算、存取等。
2.5K20发布于 2020-11-17 - 来自专栏java一日一条
高并发系统的设计及秒杀实践
高并发系统设计原则 高并发的接口/系统有一个共同的特性，那就是”快”。 在系统其它条件既定的情况下，系统处理请求越快，用户得到反馈的时间就越短，单位时间内服务器能够处理请求的数量就会越多。 大家在做设计的时候，一般会估算一个接口的量级，如果一看就有几千几万个业务对象，就不会这样设计了，但是需要警惕的是业务对象数量级可变的情况，比如随着业务发展数量会快速增长，或者某些特殊维度下业务对象特别多 涉及到业务各阶段特性的例子就是秒杀系统，在第二部分秒杀实践中我会详细介绍。 合适选择和调用缓存 除了业务特性方面，缓存是业务对抗高并发非常重要的一个环节，合理选择缓存的类型和调用缓存的时机非常重要。 秒杀实践 秒杀业务分析 秒杀业务的典型特点有： 1. 瞬时流量大 2. 参与用户多，可秒杀商品数量少 3. 请求读多写少 4. 这样专门为高并发设计的系统最大的敌人 是低流量，在大部分库存都好近，而有几个剩余库存时， 用户会看到明明还能抢却总是抢不到，而在高并发下，用户根本就觉察不到。
1.7K31发布于 2018-10-18 - 来自专栏剑指工控
PLC 系统的 7 个良好设计实践
正确的 PLC 系统设计可以为机器或过程提供多年的服务，并大大提高所有者的效率和盈利能力。在我们将 PLC 应用于机器或过程之前，让我们看一些对成功实施至关重要的设计和维护实践。 1、良好的接地实践 2、环境问题 3、设计策略 4、电气原理图和 PLC 逻辑文档 5、编程注意事项 6、人机界面使用 7、维护因素 接地 接地是一个很大的话题，但必须注意一些基础知识。 接地不良给工业控制系统带来了很多问题。每个好的面板设计都应该有一个点来连接系统接地。典型的做法是使用接地片和/或接地棒。刮掉连接接地片和接地棒的子面板上的油漆。 始终使用良好的面板构建实践。使用绞合机床线 (MTW) 并使用适当尺寸的线。通常，多股 MTW 导体用于 PLC 输入和输出。PLC 制造商还提供预接线端子模块，以方便快速现场接线。 每个模块的电气原理图都可以放在自己的图纸上，尽管大多数时候，设计人员倾向于将两个相同类型的模块放在一张图纸上。这取决于系统的大小。确保使用部件号和插槽号识别 PLC 模块。
1.1K10编辑于 2021-12-17 - 来自专栏知了一笑
分布式系统中，权限设计实践
一、权限控制 1、业务背景 在复杂的业务系统中，权限管理是最基础的模块，通过各种授权结构模型，管理用户在产品中可访问和可操作的边界，以实现系统和数据安全管理的目的： 通常在系统的任何层面都会涉及到一定程度的权限管控 采用合理的策略去管理资源的权限并不是一件简单的事，通常随着业务和系统的不断扩展，对权限体系都会带来直接的影响，所以在做结构设计时，需要相对复杂但又要避免过度复杂。 分布式系统中，通常从系统层、组织架构、权限关系三个方面去考虑可行方案。 ，从而形成系统层级的结构；这样可以避免多个应用对基础功能的重复实现，从设计层面看也更加合理。 资源粒度：设计精细的权限体系，可以灵活的管理资源开放的范围，大到应用平台的直接开放（平台管理员），小到应用中某个页面的功能点开放（业务人员），甚至细化到库表字段级的控制，可以极大的提升数据安全性。
1.1K30编辑于 2021-12-07 - 来自专栏猿天地
领域驱动设计实践：支付系统建模
从领域模型到微服务 结论 在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。 软件行业中的许多设计模式都能解决这些问题，在Airwallex，我们尝试采用领域驱动设计（DDD）的方法来为我们的支付系统建模，以管理系统设计中的复杂性。 | 什么是DDD 领域驱动设计（DDD）是由埃里克-埃文斯（Eric Evans）提出的，它是一套思想、原则和模式，有助于根据业务领域的基础模型设计软件系统。 这些战术模式将帮助你设计既松散耦合又有凝聚力的微服务。 | 如何在实践中应用DDD 想象一下，有这样一个场景： 一位顾客想在商家的网站上购买一件T恤，价格是10美元。 | 结论 在这篇博客中，当我们试图对支付系统进行建模时，我们触及了领域驱动设计（DDD）模式的各种概念和策略。
1.3K40编辑于 2022-04-22 - 来自专栏斑斓
大型系统应用边界设计原则与实践
我曾经担任某央企千万级生产系统交付方的首席架构师，负责整个系统的架构设计和架构管理。整个项目主要由三家公司、四个团队构成（各个团队下还有各自的子团队），团队人数规模大约100人。 交付模式 整个项目的交付过程以我定义的所谓“大瀑布+小敏捷”模式开展，该模式的具体形式如下图所示： 之所以采用这一方式，在于项目的每个里程碑节点必须按照合同约定的时间交付，例如在系统设计阶段结束时，必须交付概要设计说明书等交付物 微服务架构 整个系统采用了如下所示的微服务架构： 微服务架构采用了前后端分离的整体架构，后端的微服务层按照领域边界划分子领域，在各个子领域内部，则根据业务的边界识别微服务，对外提供客户端需要的业务能力 康威定律 一个好的开发团队与设计良好的架构应该遵循“康威定律”，也就是一个设计良好的系统，其架构的组织应该与开发它的团队组织保持一致。 应用边界设计原则 为了避免大量类似问题的重复出现，也为了减少不必要的工作纠纷，我根据微服务的设计原则与团队的组建原则，结合项目的实际情况，确定了如下应用边界设计原则。
1.4K31编辑于 2023-03-23 - 来自专栏芋道源码1024
领域驱动设计实践：支付系统建模
DDD 问题空间 解决方案空间 从领域模型到微服务 结论 ---- 在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。 软件行业中的许多设计模式 都能解决这些问题，在Airwallex，我们尝试采用领域驱动设计（DDD）的方法来为我们的支付系统建模，以管理系统设计中的复杂性。 有助于根据业务领域的基础模型设计软件系统。 在问题空间，你是用战略模式来定义系统的大规模结构，它专注于分析一个领域、子领域和泛在语言。 而在解决方案空间中，采用战术模式来提供一套设计模式，你可以用它来创建领域模型。 结论 在这篇博客中，当我们试图对支付系统进行建模时，我们触及了领域驱动设计（DDD）模式的各种概念和策略。
1.7K10编辑于 2022-04-08 - 来自专栏运维开发王义杰
系统设计：预订系统
系统架构 基于前面的需求，我们将设计一个预订系统。该设计将包括系统架构、关键组件的UML模型以及用Go语言实现的代码示例。 为了进一步细化预订系统的设计，我们将对关键的服务组件进行更详细的设计，包括数据库模式、RESTful API设计以及关键功能的实现逻辑。这将帮助开发团队更清晰地理解系统的工作方式和接口细节。 数据库设计 我们首先定义数据库模型以支持系统功能。 以下是针对主要功能模块的数据库模式设计： 用户模块 预订模块 支付模块 RESTful API 设计 我们为系统定义RESTful接口，以支持各种客户端操作。 建议在系统实施前进行详细的风险评估和技术验证，确保设计的可行性。
99210编辑于 2024-04-15 - 来自专栏存储公众号：王知鱼
用文件系统重构AI记忆：个人操作系统设计实践
技能系统设计原则：学习如何通过结构化指令和自动加载机制，让AI在不同任务中一致地遵循用户的优先级和工作流程 实践避坑经验：作者踩过的模式过度设计、语音提示过长、模块边界划分错误等坑，为类似项目提供了宝贵的参考 了解这一点会改变你为人工智能系统设计信息架构的方式。 我没有编写一个庞大的系统提示符，而是将个人操作系统拆分成 11 个独立的模块。当我让 AI 撰写博客文章时，它会加载我的语音指南和品牌文件。 4）操作系统：我日常是如何实际使用它的 没有执行，建筑设计就毫无意义。 以下是该系统在实际运行中的运作方式。 内容制作流程：七个阶段：构思、研究、大纲、草稿、编辑、发布、推广。 这种转变是从优化个体交互转向设计信息架构。这就好比写一封好邮件和构建一个好的文件系统之间的区别。前者只能帮到你一次，后者则每次都能帮到你。 整个系统都装在一个 Git 代码库里。 渐进式披露机制本质上是信息架构的优化，这能否推广到更广泛的AI系统设计中？是否存在一种通用的“AI记忆分层模型”？
31510编辑于 2026-03-09 - 来自专栏kubernetes中文社区
知乎容器化构建系统设计和实践
整个系统的设计目标是具备以下的能力： 较低的应用接入成本，较高的定制能力：写一个构建系统配置文件成本要尽可能简单方便，或者可以通过模板一键创建，但又要能满足应用的各种定制化的需求。 推动业界标准以及最佳实践，同时在代码合并之前就能更好把控住质量。 整个集群高可用，可扩展，以及具备较低的运维成本。 减少不稳定构建，降低问题复现成本 缓存的设计 最开始构建的缓存是落在对应的 Jenkins Slave 上的，随着 Slave 数量的增多，应用构建被分配到不同 Slave 带来的代价也越来越大。 规范和标准的落地抓手 我们希望能给接入到构建系统的提高效率的同时，也希望能推动一些标准或者好的实践，比如完善测试。 围绕着测试和测试覆盖率，我们做了以下的事情： 配置文件中强制要有测试环节。 高可用设计 集群的设计如下，一个 Node 对应的是一台物理机，上面跑了 Jenkins Slave （分别连 Master 和 Master Standby），Docker Deamon 和 MySQL
1.3K30发布于 2019-06-24 【高可用系统监控的设计原则与实践】
监控系统的设计原则与实践 高可用系统的监控设计需要遵循实时性、直观性和整体性原则，确保能快速发现、定位和解决问题。 以下是具体的设计思路和实施方案： 实时监控与告警机制 每个节点部署Agent进行数据采集，包括HTTP接口、Redis、MQ和DB等关键组件。 自动化恢复验证 问题修复后，系统自动重新检测节点状态并更新颜色。所有受影响节点状态同步恢复，无需人工逐项确认。业务指标曲线实时刷新，通过同比/环比数据验证业务是否恢复正常。 实践效果示例 假设会员数据库因慢查询崩溃： 监控大屏中会员DB节点变红，显示“慢查询堆积”。 依赖DB的会员服务、下单服务依次变红，错误提示“数据库连接超时”。 通过上述设计，系统监控从被动响应转为主动预防，事故平均解决时间（MTTR）可缩短80%以上。
17010编辑于 2025-12-18- 来自专栏crossoverJie
IM系统重构到 SDK 设计的最佳实践
SDK 设计在之前提到了 cim 在做集成测试的时候遇到的问题，需要提供一个 SDK 来解决，于是我花了一些时间编写了 SDK，同时也将 cim-client 重构了。 messageListener); ClientBuilder callbackThreadPool(ThreadPoolExecutor callbackThreadPool); }以上部分 API 的设计借鉴了 为了方便后续可能调用一些外部系统，在此基础上还支持了指定多种请求 method、指定 URL 、返回结果嵌套泛型等。@Request(url = "sample-request?
48010编辑于 2024-10-12 - 来自专栏技术一号位指南(小诚信驿站)
系统设计：在线售票系统
需求 让我们设计一个在线售票系统，销售Ticketmaster或BookMyShow等电影票。 类似服务：bookmyshow.com，ticketmaster.com 难度等级：难 1.什么是在线电影票预订系统？ 电影票预订系统为其客户提供了在线购买影院座位的能力。 这意味着系统应该是安全的，数据库符合ACID。 3.一些设计考虑 1.为了简单起见，假设我们的服务不需要任何用户身份验证。 2.系统不会处理部分票订单。 6.数据库设计 以下是我们将要存储的数据的一些观察结果： 1.每个城市可以有多家电影院。 2.每家电影院将有多个大厅。 3.每部电影将有多场演出，每场演出将有多个预订。 image.png 7.高级设计 在高层，我们的web服务器将管理用户的会话，而应用服务器将处理所有这些会话票证管理，将数据存储在数据库中，并与缓存服务器一起处理预定。
7.8K120编辑于 2022-03-06 - 来自专栏YuanXin
【系统设计】如何设计一个CMS系统
CMS 是：内容管理系统。而这个内容，是存放在具体介质上，例如云数据库中。 在 cms 中，可以创建一个“内容集”（类似于数据表），并且可以修改内容集的字段信息。 因此，一个 cms 系统就非常有用了。在使用上，非常直观。运营同学完全可以根据自身需要，创建一个新的内容集。前端进行动态化构建的时候，直接拉取对应内容集中的内容进行构建即可。 数据库集合设计 用户集合 除了用户名、密码字段，添加一个 role 字段："user" | "root"。
3K10发布于 2020-05-06 - 来自专栏师叔的搬砖之路
Python应用实践——设计一个学生管理系统
项目要求 设计一个学生管理系统 关联的主要课程目标： Python 函数和模块、Python文件的数据读取及操作等。 项目要求：设计一个学生管理系统，实现学生基本信息（学号、姓名、性别）的录入、删除和查看、读取及保存功能。 项目指导：可将学生管理系统分为六个小模块：添加学生信息模块、删除学生信息模块、显示所有学生信息模块、保存数据模块、恢复数据模块、退出系统模块等。每个功能模块用函数来实现。 ") print("2、删除学员") print("3、修改学员") print("4、查询学员") print("5、显示所有学员") print("0、退出系统 \t性别') for i in info: print(f"{i['id']}\t{i['name']}\t{i['tel']}") #用户变量循环使用，直到用户输入6，才退出系统
1.3K10编辑于 2022-09-26 - 来自专栏数据和云
【架构设计】高并发IM系统架构优化实践
摘要： 介绍如何设计一个稳定、高并发、消息保序的IM系统，以及如何通过使用存储层的高级功能来优化系统架构。 上图展示这一消息模型 发送方发送了一条消息后，消息会被客户端推送给后台系统 后台系统会先存储消息 存储成功后，会推送消息给接收方的客户端 2 确认后台架构 ? 使用前，需要确定主键列部分的结构，使用过程中不能修改；属性列部分是Schema Free的，用户可以自由定制，每一行数据的属性列部分可以不一样，所以，只需要设计主键列部分的结构。 到此，我们已经设计出了一个完整的聊天系统，虽然这个系统已经可以运行，且能处理大并发，性能也不差，但是还是存在一些挑战。 spm=5176.100239.blogcont66461.21.218KAh 1 建表 按照之前的设计，表结构如下： ?
2.6K60发布于 2018-03-07 - 来自专栏vivo互联网技术
vivo全球商城：库存系统架构设计与实践
作者：vivo官网商城开发团队 - Xu Yi、Yan Chao 本文是vivo商城系列文章，主要介绍vivo商城库存系统发展历程、架构设计思路以及应对业务场景的实践。 一、业务背景 库存系统是电商商品管理的核心系统，本文主要介绍vivo商城库存中心发展历程、架构设计思路及应对各种业务场景的实践。 本文将介绍vivo商城库存系统架构设计经验以及一些问题的解决方案。 二、系统架构设计 2.1 vivo大电商库存架构 根据vivo大电商的销售渠道与业务场景可以将库存业务架构分为3个层级：仓库层、调度层以及销售层。 性能弱，与其他系统耦合大，不能灵活扩展。 基于上述限制与产品期望，21年库存系统完成初版架构设计，此后系统不断迭代完善，形成当前的系统架构： 库存系统提供两个核心能力：交易能力和库存管理。
1.8K32编辑于 2023-03-13 - 来自专栏超级架构师
【系统设计】系统设计基础：速率限制器
在大型系统中，速率限制通常用于保护底层服务和资源。速率限制一般在分布式系统中作为一种防御机制，使共享资源能够保持可用性。 系统将这些请求时间排序在一个集合或一个表中。它丢弃所有时间戳超过阈值的请求。我们每一分钟都在寻找旧的请求并将它们过滤掉。然后我们计算日志的总和来确定请求率。 它还避免了漏桶的饥饿问题和固定窗口实现的爆裂问题 分布式系统中的速率限制 上述算法非常适用于单服务器应用程序。但是当分布式系统涉及到多个节点或应用服务器时，问题就变得非常复杂。 弹性或动态限制：在弹性限制下，如果系统有一些可用资源，请求的数量可能会超过阈值。 例如，如果一个用户每分钟只允许发送 100 条消息，我们可以让该用户每分钟发送超过 100 条消息，当系统中有可用资源时。
1.5K30编辑于 2022-05-29
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号