无法衡量就无法优化，对于互联网产品而言，不仅是推荐系统，整个 app 系统的更新迭代必然需要建立一套度量衡，来把控整个流程优化的方向。而 abtest 系统就是一个很好的进行变量控制和优化方向选取的工具，循环：衡量-发现-迭代-验证。所谓精细化迭代是一种建立在数据基础上的思维方式——用较少的成本获得较好的效果。无数据，不优化， 线上分流实验是进行推荐算法优化的必由之路。并且 abtest 不仅是推荐迭代的利器，他还可服务于所有需要逐步完善的产品迭代。有人说为什么需要 abtest ，为什么不能够前后进行实验比较；因为同时期测试的 abtest 非常有必要的原因是不同时间的测试无法说明 b 比 a 好，通常时间也是一个变量，比如电商的双十一等。
文章[2] 策略的改变，不是由我们随便“拍脑袋”得出，而是一种建立在数据基础上的思维方式，数据反馈会告诉我们做的好不好，哪里有问题，以及衡量可以带来多少确定性的增长。
高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。
AB 实验平台这几年在互联网公司得到了越来越广泛的应用，采用 AB 实验来评估产品和技术迭代效果也成为主流的业务新功能效果评估方式，数据驱动的文化在这几年得到了不少公司的广泛的认同，通过数据和指标来说明产品效果也得到了越来越多的公司的认可和应用。
产品的改变不是由我们随便「拍脑袋」得出，而是需要由实际的数据驱动，让用户的反馈来指导我们如何更好地改善服务。正如马蜂窝 CEO 陈罡在接受专访时所说：「有些东西是需要 Sense，但大部分东西是可以用 Science 来做判断的。」
系统设计不仅需要考虑实现业务功能，还要保证系统高并发、高可用、高可靠等。同时还应考虑系统容量规划（流量、容量等）、SLA指定（吞吐量、响应时间、可用性、降级方案等）、监控报警（机器负载、响应时间、可用率等）、应急预案（容灾、降级、限流、隔离、切流量、可回滚等）。
安装最新版本之后，可以看到这个流量拆分功能所使用的 API 资源并非来自 Linkerd，而是 SMI 规范的一部分。
大家好，我是虫爸。今天给大家分享一款亿级流量实验平台。在互联网行业，要上线一个策略(CTR预估、CVR预估等)，或者一个功能，如果贸然全量上线，那么如果新策略效果不佳，可能会造成不小的损失，要么丢失用户，要么损失收入。
Nginx很多人都知道可以用来做反向代理和负载均衡。但实际上Nginx可以做的远不止这些。
一开始从索引参数调整， forcemerge 任务引入等多个手段来缓解问题，但是伴随数据的快速膨胀还是遇到类似高命中查询等难以优化的问题，从而引出了索引拆分方案的探索与实施。
之前做过一个项目，数据库存储采用的是mysql。当时面临着业务指数级的增长，存储容量不足。当时采用的措施是
8规则详述： · 流量从上往下流过分流模型 · 域1和域2拆分流量，此时域1和域2是互斥的 · 流量流过域2中的B1层、B2层、B3层时，B1层、B2层、B3层的流量都是与域2的流量相等。此时B1层、B2层、B3层的流量是正交的 · 流量流过域2中的B1层时，又把B1层分为了B1-1，B1-2，B1-3，此时B1-1，B1-2，B1-3之间又是互斥的 应用场景 · 如果要同时进行UI优化、广告算法优化、搜索结果优化等几个关联较低的测试实验，可以在B1、B2、B3层上进行，确保有足够的流量 · 如果要针对某个按钮优化文字、颜色、形状等几个关联很高的测试实验，可以在B1-1、B1-2、B1-3层上进行，确保实验互不干扰 · 如果有个重要的实验，但不清楚当前其他实验是否对其有干扰，可以直接在域1上进行，确保实验结果准确可靠
伴随政府采购业务的快速发展，政采云的商品数据量也在快速膨胀，其中由 ES 进行提供的商品检索服务压力，也越来越大。由于商品模型中基础商品和交易商品的定义，导致商品本身的量会相对一般的电商场景多出一倍。
在理解了要选择怎样的指标来衡量各项业务之后，我们可以对业务有一个客观和全面的把握，可是数字本身无法告诉我们发生了什么事情，怎样可以改进。为了得到更深入的信息，我们需要用到很多的分析工具，这里我们只介绍最常用和基础的分析方法：拆分。
最近西安一码通的故障引起了业界广泛的讨论，究其根本原因还是系统未充分考虑到扩展性，在面临超过日常访问数倍甚至十倍以上的突发流量时某个环节达到了瓶颈点，并且系统不能做到自动扩缩容，最终导致了故障。
在理解了要选择怎样的指标来衡量各项业务之后，我们可以对业务有一个客观和全面的把握，可是数字本身无法告诉我们发生了什么事情，怎样可以改进。为了得到更深入的信息，我们需要用到很多的分析工具，这里我们只介绍
作者 | vivo 互联网算法团队 - Shen Jiyi 本文根据沈技毅老师在“2022 vivo 开发者大会"现场演讲内容整理而成。 混排层负责将多个异构队列的结果如广告、游戏、自然量等进行融合，需要在上下游和业务多重限制下取得最优解，相对复杂和难以控制。本文主要从业务、模型等角度介绍了 vivo 广告策略团队在信息流和应用商店混排上的一些探索和思考。 一、背景介绍 首先介绍一下什么是混排。所谓混排，如图所示就是需要在保障用户体验前提下，通过对不同队列中的异构内容进行合理混合，实现收益最优，更好
混排层负责将多个异构队列的结果如广告、游戏、自然量等进行融合，需要在上下游和业务多重限制下取得最优解，相对复杂和难以控制。本文主要从业务、模型等角度介绍了vivo广告策略团队在信息流和应用商店混排上的一些探索和思考。
上图展示了当前B站实时数仓的一个简略架构，大致可以分为采集传输层、数据处理层，以及最终的AI和BI应用层。为保证稳定性，数据处理层是由以实时为主，以离线兜底的两条链路组成，即我们熟知的批流双链路。
在理解了要选择怎样的指标来衡量各项业务之后，我们可以对业务有一个客观和全面的把握，可是数字本身无法告诉我们发生了什么事情，怎样可以改进。为了得到更深入的信息，我们需要用到很多的分析工具，这里我们只介绍最常用和基础的分析方法：拆分。 1 看数据分布 最简单的拆分方法就是不看平均值，看数据分布。因为凡是“总和”或者“平均”类的统计数据都会丢失掉很多重要的信息。例如李嘉诚来我们公司参观，这一时间我们公司办公室里的“平均资产”就会因为李嘉诚一个人 被抬高到人均几亿身家。如果有人根据这个“平均资产”数据来判定说我们办
大概去年这时候，写过一篇文章：浅谈容量测试与容量规划：https://www.cnblogs.com/imyalost/p/9630846.html
同比: 与历史同时期比较,就是与不同年份(月份)的同一时期作比较，例如2005年7月份与2004年7月份相比，叫同比。
之前自己也写过好几篇关于全链路压测的文章或者博客，最近看了infoQ上infoQ-数列科技杨德华的专栏，复盘了下自己以往在全链路压测实施方面的工作，发觉还有很多可以做的更好的地方。就以这篇文章来做个总结，顺带说说我自己实施全链路压测工作方面的一些收获和经验。
本文内容选自中国DevOps社区年会 · 2019年会，刘超老师分享的《大规模微服务场景下灰度发布与流量染色实践》实录。
最近我在研究 Nginx 1.13.4 最新的 mirror 模块，利用 mirror 模块，你可以将线上实时流量拷贝至其他环境同时不影响源站请求的响应，因为 Nginx 会丢弃 mirror 的响应。mirror 模块可用于以下几个场景：
DNS域名解析 整个过程大体描述如下，其中前两个步骤是在本机完成的，后8个步骤涉及到真正的域名解析服务器：1、浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过TTL属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名。
摘要 机器学习是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自
网络流量监控有两种方式：通过网络分路器TAP进行分流，另一种事通过端口镜像SPAN（交换机端口分析器）复制流量进行分析。
TAP分流器是一种外部网络设备，在ICT圈内已经出道多年，用户对其功能用途早已熟记于心：通过串接或并接在网络中，采集网络镜像或者分光的流量数据，可将一个端口的流量数据复制到多个端口、或把多个端口的流量数据汇聚到一个端口，还可以根据一定规则过滤流量数据再分发到一台或者多台流量数据分析设备。
现在全链路越来越火，各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型，各家方案都有所不同。最近我看了一些这方面的资料，有一些感悟。分享给大家。
微服务架构一直以来是服务治理的基本盘之一，落地到云原生上，往往是每个 K8s pods 部署一个服务，独立迭代、独立运维。
声明：本人坚决反对利用文章内容进行恶意攻击行为，一切错误行为必将受到惩罚，绿色网络需要靠我们共同维护，推荐大家在了解技术原理的前提下，更好的维护个人信息安全、企业安全、国家安全。
网络上发生的所有事件都是时间敏感的，这就是为什么在讨论数据包捕获和分析时，给数据包加上时间戳非常重要。 此功能不仅可以防止和分析网络攻击，而且还能让你检查趋势和网络延迟。
本篇文章是笔者流量治理的第一篇文章，笔者希望在这里系统的讲解下这些年以来对流量和流量治理的理解，希望对读者有所帮助，也希望读者能够及时指正文章中笔者理解不对的地方。
有赞是一个商家服务公司，致力于帮助每一位重视产品和服务的商家成功。随着移动互联网的流量增长红利渐渐褪去，商家获得新的流量越来越困难，帮助商家实现更有效的流量转化与长期目标的增长是有赞SaaS服务的应有之义；同时，随着有赞SaaS功能的不断完善，服务的商家不断增多，而业务场景也越来越复杂，考虑到有限的研发资源，提升产品和技术的迭代效率成为当务之急。
分享九个数据分析的方法。” 一、关联分析 关联分析，也叫作“购物篮分析”，是一种通过研究用户消费数据，将不同商品之间进行关联，并挖掘二者之间联系的分析方法。 关联分析目的是找到事务间的关联性，用以指导决策行为。如“67%的顾客在购买啤酒的同时也会购买尿布”，因此通过合理的啤酒和尿布的货架摆放或捆绑销售可提高超市的服务质量和效益。关联分析在电商分析和零售分析中应用相当广泛。 关联分析需要考虑的常见指标： 支持度：指A商品和B商品同时被购买的概率，或者说某个商品组合的购买次数占总商品购买次数的比例。
互联网系统，经常会有数据迁移的需求。系统从机房迁移到云平台，从一个云平台迁移到另一个云平台，系统重构后表结构发生了变化，分库分表，更换数据库选型等等，很多场景都需要迁移数据。
「原理」这个专题，主要介绍数据分析师的常用分析方法和原理。我们先从目前最常用的AB-Test讲起。
作者简介：张渐修，任职于上海同悦信息科技有限公司，从事P4可编程交换机市场工作，Wechat: Tooyumzjx。
将流量从基础设施扩展中解耦，这样就可以让 Istio 提供各种独立于应用程序代码之外的流量管理功能。除了 A/B 测试的动态请求路由，逐步推出和金丝雀发布之外，它还使用超时、重试和熔断器来处理故障恢复，最后还可以通过故障注入来测试服务之间故障恢复策略的兼容性。这些功能都是通过在服务网格中部署的 Envoy sidecar/代理来实现的。
本文介绍了ABTest平台在个性化推荐系统、搜索引擎、广告系统等领域的应用，以及通过ABTest平台实现算法优化、服务提升、数据效果提升等作用。
在实际项目中，曾经遭遇过线上5W+QPS的峰值，也在压测状态下经历过10W+QPS的大流量请求，本篇博客的话题主要就是自己对高并发流量控制的一点思考。
上一篇文章我们介绍了服务化带来的一系列问题。以及我们解决服务雪崩、链路过长问题难定位、服务调用关系错综复杂这几个问题的经历。
当业务增长越来越快，随之而来的研发规模急剧扩大、迭代上线和变更愈发频繁给线上业务带来了不小的冲击，初创公司如何应对这一难题？本文将基于店匠的实践经验，详细分析如何用最小成本发现并修复，频繁迭代上线影响线上业务稳定性和关键指标的问题。
之前有很多同学问我，性能测试中到底该如何去定位分析瓶颈并进行性能优化？感觉压测场景设计做的很全面，分析工具也用了很多，但一直无法快速的定位分析并进行优化。
领取专属 10元无门槛券
手把手带您无忧上云
