随笔分类 - 电商课题

摘要:我们的数据中台在最近两年发展得更有体系了,这与公司裂变、业务规模激增引发的,当然也跟我们高屋建瓴、高举高打分不开。 阅读全文
posted @ 2019-11-11 08:22 旁观者 阅读 (489) | 评论 (0) 编辑
摘要:我们要把别人的历史当作自己的未来,这样才能知道过去人家错在哪里,我们现在应该怎么做。 阅读全文
posted @ 2019-01-22 16:41 旁观者 阅读 (1229) | 评论 (0) 编辑
摘要:“国王做梦,”他说,“首相筑梦。” 阅读全文
posted @ 2018-10-03 01:30 旁观者 阅读 (943) | 评论 (0) 编辑
摘要:切换过程相当地魔幻,弹指一挥间,流量就切了,容就扩了,商户无感知,该收银收银,小盒子工作无碍。 阅读全文
posted @ 2018-03-30 16:58 旁观者 阅读 (1305) | 评论 (0) 编辑
摘要:你全量发布了一个新版本应用,怎么在商户的大面积投诉之前,率先发现闪退趋势呢? 如果商户投诉设备运行缓慢,你怎么分析性能瓶颈呢?坐高铁到现场吗? 阅读全文
posted @ 2017-11-20 10:49 旁观者 阅读 (1123) | 评论 (0) 编辑
摘要:知己知彼,百战不殆,了解一下过去那几年我们所经历过的各种不可抗离奇事件吧。 阅读全文
posted @ 2017-04-07 10:00 旁观者 阅读 (1142) | 评论 (0) 编辑
摘要:Summoner 是基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统。Summoner 是 JobCenter 的延伸和有益补充,它们各自有各自的应用场景。我们还会借鉴 mesos 的先进理念,进一步提升 Summoner 的集群调度能力。 阅读全文
posted @ 2016-01-08 10:52 旁观者 阅读 (3353) | 评论 (1) 编辑
摘要:大家都做这件事,一定是因为当数据量大到一定程度,数据重要到一定程度时,online schema change 和刷库不容有失,第一解决锁表问题,不能影响线上业务,第二搞定操作回滚问题,第三解救 DBA 于倒悬。 阅读全文
posted @ 2015-12-08 14:22 旁观者 阅读 (4151) | 评论 (0) 编辑
摘要:iDB 的主要目的是解决绝大部分重复、复杂的数据库运维工作 ,满足业务对数据库信息查询和快速变更需求,借此提升研发效率,保证数据库操作符合审计要求,有可追溯的变更和审核日志。 阅读全文
posted @ 2015-12-08 14:08 旁观者 阅读 (7082) | 评论 (0) 编辑
摘要:电商核心交易流程中,由于涉及的对象较多,如自家的订单中心、资金帐户中心、库存中心、支付中心,第三方支付的接口,银行,自家的支付网关等等,每个对象都可能处于不可知状态,网络消息的投递也不能保证先后顺序,还可能丢包,所以有大量的异常分支需要处理。 阅读全文
posted @ 2015-10-19 17:31 旁观者 阅读 (3331) | 评论 (0) 编辑
摘要:在这些异常流量对我们的系统或用户产生大量危害之前,系统就应该拦截。 于是,第一个问题是,如何识别异常流量。 阅读全文
posted @ 2015-09-23 10:25 旁观者 阅读 (5481) | 评论 (1) 编辑
摘要:关键词:在线支付,POS,第三方支付,清算,银企直连,快捷支付,对公对私,支付宝,对账,App 本文档适用人员:交易领域的产品研发人员 阅读全文
posted @ 2015-09-08 17:42 旁观者 阅读 (4771) | 评论 (0) 编辑
摘要:线下的传统压力测试,难以模拟真实流量,尤其难以模拟正常流量混杂着各色异常流量。所以,线下压得好好的系统,上线后可能某天突然雪崩,说好能支撑 5 倍流量的系统重构,也许流量一翻倍就彻底挂了。但办法总比问题多。 阅读全文
posted @ 2015-08-25 19:48 旁观者 阅读 (21855) | 评论 (1) 编辑
摘要:Web 站点的安全重灾区就是找回密码功能。很多工作了多年的 Web 开发工程师仍然意识不到这些基本安全原则。 阅读全文
posted @ 2015-08-13 10:56 旁观者 阅读 (2790) | 评论 (2) 编辑
摘要:如本文所示,在没有部门经理、研发经理、工程师的帮助下,我自己就能从宏观看到微观,并最终明确某个性能瓶颈的 Root Cause(当然还不够接触本质)。 阅读全文
posted @ 2015-07-15 11:33 旁观者 阅读 (4223) | 评论 (0) 编辑
摘要:一次成功的入侵渗透,并不需要是什么高危漏洞,几个普普通通的中等漏洞,搭配一次社会工程学行动,就可以搞定。 一个公司成千上万人,往少里说也有 80% 的人安全意识淡薄,有耐心的攻击者会盯好几年,穷尽各种招数,没有攻不进去的堡垒。 阅读全文
posted @ 2015-05-29 18:46 旁观者 阅读 (2709) | 评论 (0) 编辑
摘要:电商系统的分布式缓存一般是 redis 和 memcached 集群,每一个节点上会起很多实例,因为一个业务类型对应于一个端口,拆分得很清楚。既然节点很多,端口很多,业务也在变化,随时都有变动,如何管理呢? 阅读全文
posted @ 2015-05-14 11:42 旁观者 阅读 (3576) | 评论 (1) 编辑
摘要:大致想来,李丹刘奎还需要解决这么几个基础问题:绘图所依赖的监控原始数据如何收集?如何加工?如何存储?图形如何绘制,各种指标如何叠加?拓扑关系如何绘制? 阅读全文
posted @ 2015-01-23 09:48 旁观者 阅读 (17970) | 评论 (7) 编辑
摘要:说是定时任务,其实我只是登记了要调用的远端接口、通讯协议、Crontab 时间格式表达式、执行机器组、超时时间、报警接收人等而已。已经没有 crontab 了,全都是远端 WebService。由 JobCenter 按时通知对端的接口,并接收任务执行者的进度反馈和最终执行结果,这些响应均为 JSON 格式。还可以为同一个定时任务添加多个执行机器,JobCenter 保证通知成功。 阅读全文
posted @ 2014-12-27 19:43 旁观者 阅读 (17653) | 评论 (8) 编辑
摘要:即席查询和集群任务调度是大数据处理里的两个课题。 阅读全文
posted @ 2014-12-21 20:44 旁观者 阅读 (10828) | 评论 (0) 编辑
摘要:由于在商城模式下,不同频道很可能不断增加新筛选条件,导致筛选组合越来越复杂,最终可能要求我们从基于 NoSQL 的排序和筛选方案,尽快转变为基于搜索引擎的排序和筛选方案。 阅读全文
posted @ 2014-12-12 19:43 旁观者 阅读 (31849) | 评论 (7) 编辑
摘要:每个IT系统都是不同人开发的,如果每个人都设计自己的用户体系和RBAC权限体系,第一重复制造轮子浪费体力,第二大家需要记住无数系统入口和帐号密码,第三每当有离职时还得记得逐一禁用账户。 所以在 JobCenter/NotifyServer/Diamond/Dubbo 等陆续上线后,孟珂和传志于2013年又开始运作起内部统一认证系统。 阅读全文
posted @ 2014-12-12 17:58 旁观者 阅读 (7636) | 评论 (0) 编辑
摘要:最终我们还是选择自己来面对如下场景,采用 Push 模式(NotifyServer 主动向下游 Push 消息) 阅读全文
posted @ 2014-12-12 17:37 旁观者 阅读 (18273) | 评论 (1) 编辑
摘要:在这种被动的场景下,可以力保核心购买流程能走通,保证基本可用性,即确保能够下单和提交支付,保证钱能流进来,同时保证消费验证。 所以业务降级的做法是,逐一全局关闭非核心流程的业务功能。 阅读全文
posted @ 2014-12-12 17:27 旁观者 阅读 (6557) | 评论 (1) 编辑
摘要:要能做到追踪每个请求的完整调用链路,收集调用链路上每个服务的性能数据,计算性能数据和比对性能指标(SLA),甚至在更远的未来能够再反馈到服务治理中,那么这就是分布式跟踪的目标了。在业界,twitter 的 zipkin 和淘宝的鹰眼就是类似的系统。 阅读全文
posted @ 2014-12-12 16:30 旁观者 阅读 (38680) | 评论 (5) 编辑
摘要:规则库怎么来的?得建设一些方便观测的外围系统,才能发现特征、建立规则、调整参数、观察效果。所以与此类似,做了推荐服务后,就需要推荐效果评测了。 阅读全文
posted @ 2014-12-12 16:03 旁观者 阅读 (5438) | 评论 (0) 编辑
摘要:这里的“缓存”概念不只限于服务器端的“缓存”。关键词:会话串号,Cache-Control头域,缓存穿透,缓存集体失效,缓存重建,缓存雪崩,缓存永不过期,缓存计数器。 阅读全文
posted @ 2013-10-27 20:27 旁观者 阅读 (9536) | 评论 (1) 编辑
摘要:Web开发工程师请阅读下面的前端开发准则,这是第一部分,强调了过去几年里我们注意到的Web工程师务须处理的Web访问安全基础点。尤其是一些从传统软件开发转入互联网开发的工程师,请仔细阅读,不要因为忽视这些基础点而制造一个又一个的漏洞或突发事件。 阅读全文
posted @ 2013-10-15 12:15 旁观者 阅读 (8655) | 评论 (7) 编辑
摘要:关键词有:历史记录不得直接篡改原则, 交易关闭通知处理,退款处理结束通知, 掉单被动处理,掉单主动处理, 多个渠道的重复支付处理, 支付成功时商品不可售卖的处理, 订单金额变化交易流水号变化规则, 推送订单不得包含违禁词,………… 阅读全文
posted @ 2012-12-14 01:38 旁观者 阅读 (5813) | 评论 (3) 编辑
摘要:幂等性指的是,使用相同参数对同一资源重复调用某个接口的结果与调用一次的结果相同。2.1. 如何防范 POST 重复提交 2.2. 集群环境下的定时任务幂等性 阅读全文
posted @ 2012-11-22 23:52 旁观者 阅读 (12146) | 评论 (0) 编辑
摘要:RBAC 认为权限授权实际上是 Who、What、How 的问题,即可简单表述为:判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真。 阅读全文
posted @ 2012-11-17 22:47 旁观者 阅读 (9929) | 评论 (2) 编辑
摘要:与分布式缓存在高并发和高可用下所要解决问题差不多。 阅读全文
posted @ 2012-11-17 22:30 旁观者 阅读 (9956) | 评论 (5) 编辑
摘要:防篡改验证码的生成规则可以很简单:md5(cookieValue+key)或sha1(cookieValue+key),key可以是服务器端掌握的一个固定字符串,也可以很复杂(如后面的LTPA示例)。 阅读全文
posted @ 2012-11-17 22:24 旁观者 阅读 (7047) | 评论 (1) 编辑
摘要:保证整个(分布式)系统内对一个重要事物(订单,账户等)的有效操作线程 ,同一时间内有且只有一个。比如交易中心有N台服务器,订单中心有M台服务器,如何保证一个订单的同一笔支付处理,一个账户的同一笔充值操作是原子性的。 阅读全文
posted @ 2012-11-17 22:16 旁观者 阅读 (9591) | 评论 (4) 编辑
摘要:令牌桶和漏桶算法最主要的差别在于:漏桶算法能够强行限制数据的传输速率,而令牌桶算法能够在限制数据的平均传输速率的同时还允许某种程度的突发传输。 在令牌桶算法中,只要令牌桶中存在令牌,那么就允许突发地传输数据直到达到用户配置的门限,因此它适合于具有突发特性的流量。 阅读全文
posted @ 2012-11-17 22:14 旁观者 阅读 (8234) | 评论 (1) 编辑
摘要:之所以搞这么麻烦,是因为存在很多种网络结构,如 Nginx+Resin、Apache+WebLogic、Squid+Nginx。下面挨个儿讲一下。 阅读全文
posted @ 2012-09-19 01:17 旁观者 阅读 (14962) | 评论 (1) 编辑
摘要:分为秒杀器爱好者的技能点,京东商城的做法,苏宁易购的做法,建东的做法,特定商品秒杀的做法等小节。 阅读全文
posted @ 2012-09-18 03:51 旁观者 阅读 (6328) | 评论 (1) 编辑