昨天下午大神把组内几十号人召集在一起开Online bug分析大会，主要是针对近期线上事故从事故原因和解决方案两个维度来分析。...对于软件测试人员来说分析线上BUG是非常好的一个措施，这样可以检测到测试人员在测试过程中哪些地方考虑不周，或没有考虑到，从而可以提醒测试人员下次思考的范围扩大，尽可能地完全覆盖测试范围。...从分析结果的角度出发，线上bug大多都是开发人员和测试人员麻痹大意所导致的，并不是不可避免的。...经过分析得出线上的bug出现的原因基本有以下几类： 1.开发人员使用java框架错误 2.开发人员上线时合并代码不仔细，导致代码有遗漏 3.测试人员回归测试流程不全 4.多系统一起上线，缺少联调或者联调不全...这次线上bug分析有以下几个问题： 回归测试时，验证某个流程，但只验证到任务创建，就没有执行任务，上线后，该任务创建后执行会报错。 未测试幂等性，上线后，导致两次返回的结果不一样。
背景 服务启动时候会从mysql加载数据到es中，测试环境正常，线上异常卡住，不动。...分析 这一步，就是等待队列为非空的时候，才会执行下去，但是现在队列一直为空，线程都在等待。...因为我加载mysql采用的是多线程方式，且通过数据量的最大id/ 1000（每次加载1000） 个线程数。...所以，这次查看，直接给我整了1W多个线程，再次查看总数据量总共才40W，那么1w * 1000，那岂不是1000W了，所以，我怀疑表数据的id有问题，后面发现果然是，id是从1000W多开始的，而不是从...0开始，那么就导致前面的数据队列任务个数一直为0。
购物中心当中的兼顾吃喝玩乐的服务体验，以及通过融合社交与消费功能的大数据平台，已经比其他线上购物平台更加受到消费者的青睐。...对于线下营销来说，除了要利用对海量数据进行收集和分析之外，购物中心需要精细化运营，避免同质化，在激烈的竞争中脱颖而出。...实现精细化运营必定是在数据驱动下的，没有数据的驱动，根本谈不上精细化运营，购物中心需要数据驱动经营分析辅助营销。 购物中心整体消费群、消费习惯发生了变迁。...、最容易理解和验证的着力点，当然技术难度也高，需要全触点的数据采集和打通整合，经过标签处理工具、分析引擎、营销引擎、触发引擎。...实施场景化营销需要有三个支撑：数据支撑、分析支撑、触点支撑。
这啥玩意？文件开头字节为 Yy，不是什么常见的文件格式，内容也基本上没有完整的有意义的字符串，一度陷入沉默……
，上表省略了许多字段，但不影响我们分析； 这个表用来保存用户的收货地址，下单时需要选择相应的收货地址；通过查看日志平台日志，出问题的主要发生在添加地址的场景。...发现问题后，第一时间断定是多次请求了，因为通过相关SQL语句分析，上面的语句只会影响到某个用户自己的地址，没有操作太多的数据； 通过查看日志平台的日志，也证实了假设。...为什么同一个用户请求同时出现2次，这个后面分析；先分析执行同样的SQL，什么会发生死锁呢，可以复现下，先插入数据： INSERT INTO `oneplus_user`....还有一个问题，为什么同一个用户添加地址的请求同时会出现2条，发现代码中用了Redis锁，锁定时间是2秒，但数据库因为用的是5.6版本的，无法设置超时时间，也没有定时查询过长时间的查询机制，导致应用服务器认为请求超时了...解决方案有两个： 1、Redis锁和数据库执行时间保持一致； 2、Update语句写简单点，先找出更新之前哪条是默认的，直接将这条更新为非默认就行了；
背景 索引数据73522618，本次改动需要给索引添加一个新字段scope，并设置一个默认值为"LXF"。在本次上线之后，新录入的数据将会通过代码默认赋值"LXF"。...本次Reindex操作在不影响线上正常使用的前提下，顺利切换索引。...PUT /regroupmembers-21.02.22-010000/_settings { "refresh_interval": "30s" } 设置副本分片 设置副本分片为0，减少在索引数据过程中平衡分片性能损耗...，所以需要再次执行Reindex，将这期间的数据再录入到新索引中，并记录下这次执行完之后的时间结点。...在执行切换别名之后到服务上线之前，这期间录入的增量数据，在scope字段上是没有任何默认值的，所以需要手动修复这期间产生的增量数据。
经过内存 dump 分析，发现竟然发送了一个 400 M+ 的报文，由于 HTTP 工具没有做发送大小的校验，强行进行了传输，直接导致了线上服务整体不可用。...问题分析 为什么同样是 JSON 序列化，fastjson 没出过问题，而换成 gson 之后立马就暴露了呢？...通过分析内存 dump 的数据，发现很多字段的值都是重复的，再结合我们业务数据的特点，一下子定位到了问题 -- gson 序列化重复对象存在严重的缺陷。 直接用一个简单的例子，来说明当时的问题。...模拟线上的数据特性，使用 List 添加进同一个引用对象 Foo foo = new Foo(); Bar bar = new Bar(); List foos = new ArrayList...以模拟线上的业务数据。 重复次数：200。即 List 中包含 200 个同一引用的对象，以模拟线上复杂的对象结构，扩大差异性。 序列化方式：gson、fastjson、Java、Hessian2。
jps or ps aux | grep java 二、生成dump文件 jmap -dump:live,format=b,file=xxxx.bin 进程ID 三、查看dump文件： jhat启动分析
主要在测试阶段，由开发人员在自测过程中或者有测试人员发现 线上问题：此阶段发生在上线后，也就是在正式环境或者生产环境。...主要是不符合产品的需求逻辑，可能会影响用户体验 线上故障：这个阶段是最严重的，对公司的收益、用户体验都会造成影响，主要为服务不可用等 在本文的示例中，我们针对的第三个阶段，即线上故障进行定位和分析的一种方式...当时第一反应是有人手动重启了，于是在组内群里问了下，没人动线上，看来问题比较麻烦。...问题解决 在整个bug的分析和解决过程中，定位segfault是最困难的地方，如果知道了segfault的地方，分析原因，就相对来说简单多了。当然，知道了崩溃原因，解决就更不在话下了。...结语 遇到线上问题，一定不能慌，如果是频繁的coredump或者重启，那么就先回滚到上个版本，然后再分析和解决问题。
今天线上环境出现一个数据的误操作问题，说说抽象出来的场景吧： 某个数据清理shell脚本里面包含了形如MySQL的连接串： mysql -uxxx -pxxx -hxxx -Pxxx -D xxx...-e "drop table xxxx"; 本身这个脚本内容是清理某个特定的实例A的过期数据表的，但是运维同学想要用它清理某个离线的从库实例B的数据，修改连接串信息的时候，修改了账号、密码、端口、数据库以及表信息...，漏掉了host信息，恰好有这么一个线上实例，于是就被清理掉了。...其实这个关键就在于要清理的实例，是个离线从库，除了IP地址不一样，其他登录信息和线上实例一模一样，所以极容易发生错误。...在数据恢复的同时，我在设想这个场景应该如何避免，我个人认为更多的还是脚本风格上的问题，设想这么2个脚本： 脚本1： #!
双11期间,各大线上购物商城纷纷亮出优惠绝招。与往年不同的是,竞争一路延伸到了消费金融领域,今年不只比低价,更比“赊账”。 天猫分期购VS京东白条 日前,记者采访了蚂蚁微贷工作人员元秋。...大数据支撑贷款授信 “本质是商户和蚂蚁微贷之间的保理业务。蚂蚁微贷通过复杂的大数据运算,结合风控模型,为符合资质的消费者判定可用的分期额度。”...京东金融相关负责人介绍,京东白条通过对消费、金融的大数据深入分析,对用户的消费记录、配送信息、退货信息、购物评价等数据进行风险评级,寻找到符合风控标准的用户。...由此看来,天猫分期购和京东白条敢于作“赊账”,敢于突破传统银行信用卡业务的严格审核制度,都是基于对海量消费数据的分析,形成对消费者信用的判断。 ...专家指出,互联网金融的核心竞争力在于借助对大数据的挖掘与分析,降低信息不对称、减少交易成本,进而提升资源配置效率并促进经济增长。 见大众日报：大数据“撑起”线上消费金融
二、问题分析 目前正式环境使用数据库相关依赖如下： 依赖 版本 mysql 5.1.47 hikari 2.7.9 Sharding-jdbc 3.1.0 根据以上描述，提出以下问题： 1、com.mysql.jdbc.NonRegisteringDriver...可以考虑优化minimumIdle、maximumPoolSize、idleTimeout、maxLifetime这些参数，下一小节我们分析一波 三、问题验证 线上模拟环境 为了验证问题，我们需要模拟线上环境...，调整maxLifetime等参数~压测思路如下： 1.缓存系统模拟线上的配置，使用压测系统一段时间内持续压缓存系统，使缓存系统短时间创建/废弃大量数据库连接，观察 NonRegisteringDriver...四、问题解决方案 由上面分析可知，问题产生的废弃的数据库连接对象堆积，最终导致 full gc 时间过长。所以我们可以从以下方面思考解决方案： 1、减少废弃的数据连接对象的产生和堆积。...【建立巡查系统】 这个我们目前还没有经过实践，但是根据上面分析结果判断，定期触发full gc可以达到每次清理少量堆积的数据库连接的作用，避免过多数据库连接一直堆积。
前提是线上 JVM 配置了以下参数： [题外话：JDK 版本 1.6，现在大部分互联网企业应用系统应该是 1.8 以上了吧 ] # 在控制台输出GC情况 -verbose:gc # GC日志输出 -XX...GC 日志可视化 首先获取到线上 GC 的日志文件后，通过在线日志分析工具（GCeasy）上传文件分析，网址：https://gceasy.io/ ?...接着看 Dump 文件分析 通过 MAT 分析 dump 文件（可参考这篇文章【MAT的使用】），导入 dump 文件即可，等 MAT 解析完会出现如下图所示的界面： ?...查看代码，看看是否是 SQL 查询条件缺失，导致返回了表中的所有数据。 [题外话：建议后端服务做参数校验或限制数据库最大返回条数。] 6....小结 通过三步法定位线上环境 JVM 问题，如频繁 Full GC 、内存泄漏或发生 OOM 现象，即将 GC 日志、Dump 文件及 APM 监控系统结合在一起观察分析，寻找出问题产生的根本原因，然后才能对症下药
这个东西是决定了你的每个Batch要存放多少数据就可以发送出去了。比如说你要是给一个Batch设置成是16KB的大小，那么里面凑够16KB的数据就可以发送了。...因为理论上来说，提升batch的大小，可以允许 更多的数据缓冲在里面，那么一次Request发送出去的数据量就更多了，这样吞吐量可能会有所提升。...，这样也不太好其实，会导致你的Batch形同虚设，一直凑不满数据。...这个选择提供了最小的时延但同时风险最大（因为当server宕机时，数据将会丢失）。 1：表示获得leader replica已经接收了数据的确认信息。...如果没有足够的数据返回，请求会等待，直到足够的数据才会返回。
本文将结合一个线上案例，分析如何正确设置 MySQL 慢日志参数和使用慢日志功能，并介绍下网易云 RDS 对 MySQL 慢日志功能的增强。...下面，我们以这个线上案例为依托，介绍下该如何正确配置慢日志参数： 有用户报告，他们使用的多个 RDS 5.7 版本实例慢日志异常，明明执行了一分多钟的 SQL 语句，却没有记录到慢日志中。...如果用户没有显式指定 slow_query_log_file，则 MySQL 将其初始化为 host_name-slow.log，host_name 即为运行 mysqld 的主机名，慢日志文件默认位于 MySQL 数据目录...问题原因之所在 由于数据库实例中可能有较多不走索引的 SQL 语句，若开启 log_queries_not_using_indexes，则存在日志文件或表容量增长过快的风险，此时可通过设置 log_throttle_queries_not_using_indexes...这个线上问题似乎已经定位到了，就是系统产生的不走索引的慢日志太多，而设置的 log_throttle_queries_not_using_indexes 太小，导致无法正常记录用户未走索引的慢日志。
然而，与传统技术不同的是，单细胞测序技术所产生的数据量往往远超传统的基因芯片和RNA-seq数据，这就为单细胞数据的处理和分析带来了极大的挑战和机遇。...： 数据获取和清理 质量控制和筛选 多样本、多批次的数据整合分析 细胞亚群的鉴定、注释和功能注释 肿瘤细胞和正常细胞的鉴定和拷贝分析 拟时序分析分析 细胞转录活性调控分析 细胞间通讯分析 基于RNA-seq...授人以鱼不如授人以渔 然而，目前没有哪个软件能靠简单的点点鼠标就能完成高质量的单细胞数据分析，甚至很多课题组在将单细胞外包给一些单细胞测序服务商后，拿到的数据不符合预期甚至完全无法使用和发表。...因此，为了广大研究生，包括科研小白和代码小白能顺利开展承担单细胞测序数据的分析能力，我们精心设计了一套基于R语言的完整版单细胞RNA测序分析课程，从R语言入门循序渐进到实际开展单细胞数据分析，满满干货！...让你尽快熟悉完成上述9大数据分析的能力，从而课题组里单细胞数据分析的任务，成为别人眼中的“科研达人”！
下载数据集请登录爱数科(www.idatascience.cn) 该数据集包含零售企业在线订单的数据，目的是找出如何深入研究此数据集，为零售业务制定战略性业务决策带来意义。...数据预览 3. 字段诊断信息 4. 数据来源 来源于Kaggle。
，尽而快速止血，本文主要是从线上监控的质量方向来保障实时数据的质量。...，此处明细数据落库的必要性是为了方便排查线上监控问题。...示例如下： 四、监控告警处理 上述补充的监控用例触发告警后，问题的排查流程可以参考下图，对于数据延迟告警，可以看kafka积压现状，本次不赘述，流程中核心的步骤(标红)为： 查看&分析明细数据 重放数据...针对核心步骤“查看&分析明细数据”，在“上下游数据对比”方案中有将明细数据落库，通过接口调用展示到页面，减少捞数据/查询数据的时间，如图： “重放数据”操作亦有平台支撑，通过和开发大哥一起搞“实时数据恢复演练...线上实时数据质量的保障，除常规的测试方法覆盖外，线上实时监控针对目前线上实时数据质量保障策略中作为强有力质量辅助手段，填补了实时数据线上监控空白，从可观测层提前感知数据质量的健康情况，对后续数据故障演练
数据层面沿用之前老版服务的数据库结构，部分库字段进行修改。 最终目的：服务实现切换，数据实现切换(老库到新库)，不能停机升级，尽量减小对用户影响。...保证日志的统一性，方便日志同步服务同步数据。 ? 步骤二 开发一个数据同步服务syn-data-service，将旧库的数据同步到新库中。 ?...步骤三 当数据同步完毕后，将new-service设置为暂不可写数据(日志同步很快，会牺牲部分用户体验)。 且开发一个日志同步工具syn-log-service，将日志同步到新库中 ?...4，步骤四 开发一个compare-service，进行数据校验 ? 5，步骤五 数据没有问题后切换为new-db，用户执行的新增、修改、删除 双写到日志和new_db中。 ?...6，步骤六 兜底策略：如果发现数据有大规模不一致或者大规模数据丢失的情况，可以通过日志回写到old_db中，然后切换服务到old_server。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
