话题公司 › 京东

公司:京东

关联话题: JD

京东是中国最大的电子商务公司之一,成立于1998年。公司提供在线零售、物流配送、支付服务等一系列互联网服务。京东市场规模庞大,是中国最大的网络零售商之一。随着国内电子商务市场的不断发展和技术的不断提升,京东已经成为中国互联网行业的领导者之一。

浅谈电商付费会员触点设计

本文将从会员生命周期各阶段设计侧重,并以一号会员店为例,探讨如何做好会员触点设计。

最全的【DDD领域建模】小白学习手册

本文系统地讲解DDD到底是什么,解决了什么问题,及一些建议和实践。主要是思想的一种碰撞和分享,希望能对朋友们有所启发或帮助。

大数据实时链路备战——数据双流高保真压测

大数据实时链路是数据中台的核心,如何保障实时链路在大促期间的时效和稳定性,是备战的重中之重,本文介绍了实时大数据链路的双流建设和高保真链路压测实践,为大数据实时链路的大促保障提供了一种有效的解决方案。

Sharding-JDBC分库连接数优化

配运平台组的快递订单履约中心(cp-eofc)及物流平台履约中心(jdl-uep-ofc)系统都使用了ShardingSphere生态的sharding-jdbc作为分库分表中间件, 整个集群采用只分库不分表的设计,共16个MYSQL实例,每个实例有32个库,集群共512个库。

当每增加一台客户端主机,一个MYSQl实例最少要增加32个连接(通常都会使用连接池,根据配置的最大连接数,这个连接数可能会放大5~10倍).并且通常一个系统都会分为web,provider,worker等多个应用,这些应用共用一套数据源.随着应用机器数的增加,MYSQL实例的连接数会很快达到上限,这就对系统的扩容造成了阻碍,无法横向的增加机器数,只能纵向的提高机器的配置来应对流量的增长。

作为京东物流的核心系统,业务增长迅速,系统所承接的流量也是逐渐增加,所以急需解决这个制约系统扩展的瓶颈点。

百万并发场景中倒排索引与位图计算的实践

Promise时效控单系统作为时效域的控制系统,在用户下单前、下单后等多个节点均提供服务,是用户下单黄金链路上的重要节点;控单系统主要逻辑是针对用户请求从规则库中找出符合条件的最优规则,并将该规则的时效控制结果返回客户端,比如因为临时疫情等原因针对仓、配、商家、客户四级地址等不同维度进行精细粒度的时效控制。

该系统也是Promise侧并发量最大的系统,双11高峰集群流量TPS在百万级别,对系统的性能要求非常高,SLA要求在5ms以内,因此对海量请求在规则库(几十万)中如何快速正确匹配规则是该系统的技术挑战点。

Ui2Code+ChatGPT助力低代码搭建

即时设计平台是一个即时搭建c端页面的智能开发平台,支持通过导入设计稿完成ui2code,在此基础上完成前端可视化搭建,同时支持通过大语言模型完成一句话需求生成前端页面。

618技术揭秘 - 大促弹窗搭投实践

弹窗作为渲染氛围、引流、促销玩法等强触达营销工具,在日常及大促等场景中,有着广泛应用。 我们将在本文中探讨本次618期间,如何通过快速的搭建,将运营的想法及素材落地为投放到前端呈现的弹窗。

ChatGPT的探索与实践-应用篇

chatGPT对于人工智能领域的意义不言而喻,及时地掌握并利用好这份工具,对于降本提效有着很积极的意义,本文篇着重GPT在实际开发工程当中的应用,恰逢今年京东20周年庆,文末会介绍如何与618大促实际的业务相结合,提升应用价值。

浅谈一号会员店如何高质量拉新

本文将以京东一号会员店为例,从了解自身产品定位、明确高质量客群画像、寻找渠道定向拉新、平台价值传达设计,四个方向浅谈高质量拉新策略。

限速神器RateLimiter源码解析

RateLimiter是谷歌开源的一款轻巧限流限速组件,简单实用,设计精妙,本文结合示例对其源码进行了相关分析解读,包括代码层级、处理流程、数据流转、计算逻辑等, 希望能够帮助大家了解和使用。

618技术大揭秘:Switchquery秒级配置触达平台的设计与实现

Switchquery是一个秒级触达的高性能移动配置下发平台,特别适用于对实时性要求较高的配置下发场景。本文介绍秒级触达能力的实现原理和设计以及在618大促场景下的实践。

随机高并发查询结果一致性设计实践

物流合约中心是京东物流合同管理的唯一入口。为商家提供合同的创建,盖章等能力,为不同业务条线提供合同的定制,归档,查询等功能。由于各个业务条线众多,为各个业务条线提供高可用查询能力是物流合约中心重中之重。同时计费系统在每个物流单结算时,都需要查询合约中心,确保商家签署的合同内容来保证计费的准确性。

“标签Tag”设计分析

标签样式设计或重或浅,单纯来看仅仅是一个很小的视觉设计,但是对于用户而言通过标签可以更快获得关键信息,对于产品/平台而言,标签也承载了一定的产品策略。

基于ClickHouse解决活动海量数据问题

魔笛活动平台要记录每个活动的用户行为数据,帮助客服、运营、产品、研发等快速处理客诉、解决线上问题并进行相关数据分析和报警。可以预见到需要存储和分析海量数据,预估至少几十亿甚至上百亿的数据量,所以需要选择一款能存储海量数据的数据库。由于是通过接收MQ存储或者API方式存储,所以对实时写入性能也有一定要求。同时可能后续还需要一些实时数据分析等。

关于接口可维护性的一些建议

在用户剧增的互联网时代,作为主流架构的微服务架构,经常需要面对数据众多的系统,软件维护成本更是日趋陡增。本文结合实际工作体验,从可维护性的角度,提出了几个非常切实可行且行之有效的技巧和建议,涉及了多个几个方面,覆盖了从开发到维护的主要流程。

移动端APP组件化架构实践

对于中大型移动端APP开发来讲,组件化是一种常用的项目架构方式。个人最近几年在工作项目中也一直使用组件化的方式来开发,在这过程中也积累了一些经验和思考。

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-28 20:45
浙ICP备14020137号-1 $bản đồ khách truy cập$