Monaco Editor 是一个浏览器端的代码编辑器库，同时它也是 VS Code 所使用的编辑器。Monaco Editor 可以看作是一个编辑器控件，只提供了基础的编辑器与语言相关的接口，可以被用于任何基于 Web 技术构建的项目中，而 VS Code 包含了文件管理、版本控制、插件等功能，是一款桌面软件。Monaco Editor 的 GitHub 仓库中不包含任何实际功能代码，因为其源代码与 VS Code 在同一个仓库，只是在版本发布时会构建出独立的编辑器代码。

在日常开发工作中，我们几乎需要天天与数据库打交道，作为一名只会CRUD的SQL BOY，除了每天用mybatis-generator自动生成DAO层代码之外，我们几乎不用去care数据库中如何处理并发请求，但是突然某一天MYSQL数据库告警了，出现了死锁，我们的内心慌的一匹，不禁想问：这不就是个普通查询吗，咋还锁起来了？

为了避免慌乱的表情被主管捕捉到，我们需要提前了解一下数据库中到底有哪些锁。

在MySQL中，其实将锁分成了两类：锁类型（lock_type）和锁模式（lock_mode）。

锁类型描述的锁的粒度，也就是把锁具体加在什么地方；而锁模式描述的是到底加的是什么锁，是读锁还是写锁。锁模式通常和锁类型结合使用。

拆库&数据迁移说白了，考验的不是一个人的技术功底，而是一个人干活的细致程度，以及抗压能力。无论在哪个公司，数据库迁移的机会都不会太多，因此，我也是非常珍惜这次历练，用阿里的一句老话来说就是 “因人成事，借事修人”。写这篇文章的目的主要是自己进行一个总结，也希望能给需要的同学们一些参考。

常见的编程语言，不论强类型弱类型，还是Just In Time(JIT)或Ahead of Time(AOT)的语言，都会涉及到设计模式，其中最经典的就是单例模式，有两种基本形式称为 Meyers Singleton ， Gamma Singleton, 那么他们多线程安全吗？

论文无论是对于后续的研究还是应用落地都具有较高的参考价值。

本文重点介绍了下优化器的基于规则的其中一部分优化，更多的偏重于SQL中的基本操作符。

本篇从业务场景出发，介绍了面对一个复杂需求，拆解重难点、编码实现需求、优化代码、思考个人成长的过程。

会介绍一个运用策略模式的实战。需求和编码本身小于打怪升级成长路径。

闲鱼消息系统经过几代开发的建设，目前稳定的支撑亿级消息体量。在消息系统建设过程中，我们经历了从简单到复杂，从困扰到破局，每一次的技术改变都是为了更好的解决当下业务面临的问题。“忆昔午桥桥上饮，坐中多是豪英“，此文记录闲鱼消息系统技术变迁，以期在此基础上汲取更多经验。

多元索引是表格存储产品中一个重要的功能，多元索引使用倒排索引技术为表格存储提供了非主键列上的快速检索功能，另外也提供了统计聚合功能。表格存储近期开放了SQL查询功能，SQL引擎默认从原始表格中读取数据，非主键列上的查询需要扫描全表。开启了多元索引之后，如果一个查询的过滤条件或者统计聚合可以下推至多元索引执行，那么SQL引擎将部分查询计划转换为多元索引请求，将从多元索引中获取数据，提高查询效率。

故事要从两个「颤抖」的 bug 说起。

本文将从不同类型播放问题出发，阐述优酷技术团队在播放体验优化实战中的经验。

作为一线的开发人员，大家是不是都经历过和产品吵得不可开交的经历，甚至最后谁也无法说服谁，只能将问题上升。最后由老板出面解决，而大多数情况下老板还真能够以某种方法去解决，并且是一个双方都能接受的方案。这个时候可能大部分同学会认为是老板的权威，地位导致了这一结果。其实这很不准确（可能有一部分原因但绝对不是主要原因）其实更多的是各个老板们有比一线开发更强的产品力，能够听懂对方的诉求和抓住矛盾点并且给出解决方案。同时其中的表达方式更容易让彼此接受，才导致了最终你看到的老板出马，问题解决，好像自己的观点继续保持了，同时对方也留有余地。那这里这项重要的能力来源于什么呢？其实我认为更是一种产品思维的方式。

‍‍‍‍‍‍‍‍本文将针对开发过程中依旧经常出现的SQL编码缺陷，讲解其背后原理及形成原因。

每天打开数据监控看板，观察当日业务KPI的情况，已经是互联网人的日常工作内容之一，数据指标波动对于一个非稳定期的业务是常态。波动分析的本质是通过统计和比较来表达波动背后的规律和问题。业务的数据指标都具有固定的波动周期，而且每个周期内数据的变化应该趋于稳定，但在数据监控体系里的日报、周报、月报中某数据指标突然不再符合预期的稳定变化，这就是我们所说的数据出现异常波动。

作为互联网设计师，面对不断变化的业务内容和场景，不仅需要掌握基本的专业设计方法，同时也要求熟悉业务，在深入分析业务痛点的基础上，洞察设计创新机会点，助力业务发展。

今天小编给大家推荐6个业务分析模型与方法，可运用在内容营销评估、产品设计分析、用户增长设计、阶段性产品设计复盘等方面。

订单系统存在于各行各业，如电商订单、银行流水、运营商话费账单等，是一个非常广泛、通用的系统。对于这类系统，在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展，以及各企业对数据的重视，需要存储和持久化的订单量越来越大，数据的重视程度与数据规模的膨胀带来了新的挑战。首先，订单量对于数据的存储、持久化、访问带来了挑战，这不仅增加了开发面对的困难，也为系统的运维带来了挑战。其次，随着大数据技术的发展以及运营水平的不断提高，订单数据的后续数据分析工作，如流批处理、ETL，也越来越重要，这也对数据的存储系统提出了更高的要求。

本文提出了一种基于MySQL + Tablestore 的大规模订单系统设计方案。这种方案基于分层存储的思想，使用 Tablestore 辅助 MySQL 共同完成订单系统支持。在系统中，利用 MySQL 的事务能力来处理对事务强需求的写操作与部分读操作；利用 Tablestore 的检索能力、大数据存储能力等弥补 MySQL 在功能上的短板。