IT瘾方法推荐

数据库迁移的一种方法

Tue, 11 Nov 2025 17:16:58 CST

当数据库记录突破 10 亿条，原本几毫秒的查询变成几秒钟，批处理任务跑上数小时，这样的性能瓶颈对任何系统都是灾难。但更大的挑战在于，这是金融系统的支付、订单和账本数据，业务不允许一秒钟的停机时间。这篇来自惊心动魄的实战案例给出了一个渐进式的解决方案。核心思路是把风险拆解成可控的小步骤：先迁移不再变化的冷数据，按主键分块并行处理，暂时禁用索引以提升速度。接着通过双写机制捕获实时流量，每笔新交易同时写入新旧两个数据库，失败的写入推送到 Kafka 队列反复重试，确保数据最终一致。最巧妙的设计是影子读阶段。用户请求仍然从旧库读取，但每个查询会在后台悄悄对新库执行一遍，比对结果差异。这个过程持续数周，让团队发现了测试环境永远抓不到的问题：时区处理差异、NULL 值的默认行为、字符排序规则不同。这些都是真实流量才能暴露的坑。最后的切换选在凌晨流量最低时进行，提前通过合成查询预热新库的缓存和索引，然后通过功能开关逐步转移读流量。团队盯着 Grafana 面板上的延迟、错误率和业务指标曲线，24 小时后才确认切换成功。这个方案对于数据库迁移，比如信创改造的时候很有借鉴价值。我认为这里有三个关键的设计：一是渐进式风险控制，每一步都可以独立验证和回滚；二是用真实流量做验证，影子读比任何测试都更能发现兼容性问题。三是可观测性优先，从数据库内部的 WAL 日志、缓存命中率，到业务层的订单量和收入流量，全程监控让团队能及时发现异常。

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库 - 即刻App

Tue, 15 Oct 2024 10:40:49 CST

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库，找使用这个库的 project showcase。

起源是公司内部最近出现了一个我和 leader 都觉得惊为天人的产品。但是因为是保密项目我们能获取到的信息不够，我们判断这种交互模式和 UI 体验是借鉴了某个海外产品，大概率不是我司的原创。但是因为这个产品是很垂类的 B 端场景，加上保密项目的原因内部获取不到什么技术方案和竞品调研。

灵机一动发现这个产品的核心技术库是 xy-flow（一种画布容器解决方案），于是便从 xy-flow 的官网找到了市面上使用 xy-flow 的 project showcase。

从 project showcase 中，我看到了太多太多以前从未想到、从未接触的垂类场景：

- JSON 与工作流打通的 JSONSea
- 数据监控与工作流画布结合的 Redata
- 客服与弹窗 rpa 工作流的 Botfront
- 与地理数据结合的物流系统 Geoplex
- 包括我们自己的竞争对手 retool 和 wix 的 workflow
- …

这些都在使用 xy-flow 构建工作流、画布容器。今天几分钟的时间，从这一个基础库我看到了许多从未接触过的业务场景，这些业务场景背后代表的是一定数量的用户群体以及潜在的同类型竞品。代表着某个行业、某个市场。

这种查找需求的方法之前 @哥飞飞哥也在社群和公众号分享过类似的，并且可操作性更强范围更广：通过产品的入口流量、出口流量挖掘需求，以及榜单、外链。具体的操作和知识可以去「哥飞」公众号上刷一遍学习一下。

习得了某个方法某个知识后，举一反三在生活工作场景中用出来、总结出来，那种感觉真的是不一样的。

总得来说，这种找需求的方法考察的是多角度多维地看待问题。直接看是现象，从上游看是解决方案，从下游看是业务场景。

reactflow.dev

提高大脑效率的7个方法

Fri, 16 Aug 2024 08:28:34 CST

本文来自微信公众号： L先生说（ID：lxianshengmiao），作者：李睿秋Lachel，原文标题：《激活大脑潜力的7个方法》，题图来源：AI生成

提高大脑效率的七个简单方法

• 听喜欢的快节奏音乐激活大脑

• ‍♂️ 在散步时学习和思考

• 利用发呆时间回放记忆

今天的文章，我想跟你分享7个简单有效的小技巧。

它们可以激活你的大脑，让大脑“火力全开”，让你无论是学习还是思考，都能起到更高效、更专注的效果。

希望今天的推送，能够为你提供一点帮助和启发。

1. 用音乐激活前额叶皮质

你平时喜欢听音乐吗？如果是的话，这可能是一个好消息。

我们知道：前额叶皮质是大脑的“控制中心”，它是各种输入信息汇总的枢纽，又经由它将信息分门别类地传递向其他脑区，协调整个大脑网络的活跃。可以说，它决定了我们的认知和思考能力。

而这其中，又以背外侧前额叶（DLPFC）尤为重要：它跟工作记忆、计划、决策、推理以及信息的调用密切相关，甚至也是人类个体智力差异的重要生理基础。

那么，有什么方式可以锻炼DLPFC呢？2022年的一项研究发现： 适当的音乐，似乎能刺激到这个部位，让它变得更活跃，从而让我们的头脑变得更清醒，思维变得更高效。(Fukuie等，2022)

什么叫“适当的音乐”呢？研究认为，这需要满足两个条件：一是这些音乐是你所喜爱的，能够唤起你的兴奋与愉悦感；二是它们必须有一定的律动感和节奏感，能够让你产生想要随之摇摆的冲动。

原因在于：DLPFC跟负责运动和感觉输入的脑区是紧密相联的。因此，聆听有律动感和节奏感的音乐，可以借由让身体产生一种有韵律的运动感，来间接刺激DLPFC。

当然，运动本身也能起到同样的作用。不过显然，听音乐比运动更简单，门槛和难度也更低。

不仅如此，大脑会将快节奏的音乐跟快乐、兴奋等感受联系起来。因此，听快节奏的音乐还能改善情绪、振奋精神，提高大脑的唤醒程度，让大脑变得更活跃。

因此，如果你平时有听音乐的习惯，不妨有意识地寻找一些快节奏的音乐，加入自己的歌单，让它们成为你的助力；如果你没有这个爱好，也不妨试着去培养一下。

不过， 建议是在空闲的时候和工作之前听，而不要在工作的同时听音乐。研究发现：一边工作一边听音乐（无论是歌曲还是纯音乐），对创造力、记忆力和理解能力都有害。（E.Threadgold等，2019）

原因可能在于： 音乐本身会吸引我们的注意力，抢占一部分认知资源，从而使得我们能够投入到工作上的资源变得更少。

因此，建议在工作时使用白噪音，降低周围环境的声音和刺激对注意力的吸引；而在闲暇没事时则听听音乐，唤醒你的大脑，尤其是在自己情绪较为低落、状态不佳时，会更有振奋精神的帮助。

2. 在散步时学习和思考

散步，是我践行了许多年的爱好。每当我有比较复杂的问题需要思考时，或者陷入瓶颈时，我就会出门走一走。一边踱步，一边在脑海中把问题整个过一遍。

一般来说，走着走着，问题可能就突然迎刃而解了。又或者，脑海里会涌现出一些奇思妙想的点子，想到一些全新的思路和可能性……

这些，都是坐在家里所无法获得的。

为什么散步会有这样的效果呢？原因在于： 散步对大脑是一种非常有效的按摩，它能极大地改善大脑的认知能力，让大脑变得更清醒。

比如：当我们步行时，脚步对身体的反作用力会在血管中形成细微的湍流。它可以让更多的血液和氧气进入大脑，从而提高大脑的工作能力。

再比如：散步这种高度有节奏感、韵律感的活动，能够让大脑处于一种平衡的、舒适的状态里，对脑波活动进行调谐，让各个脑区之间的协作更紧密高效。

同时：散步可以促进BNDF（脑源形神经营养因子）的释放，提高突触的可塑性，从而让我们对知识记得更牢、思维更清晰。

以及，散步是一种高效的放松和休憩。它能够让我们从注意力的牢笼中挣脱出来，让我们疲惫不堪的注意力得到放松和喘息，从而重新恢复精力。

2014年一项研究发现：散步可以有效地提升创造力，并且这种效应在散步结束后还能持续一段时间。（Oppezzo&Schwartz，2014）

原理很简单：当你的思维彻底放松下来时，你会暂时关闭外界的信息输入，而任由思绪在后台随机地、踊跃地激活各种不同的节点。这时，就有几率产生“远距联系”，把原本无关的节点联系起来。反映在外，就是产生创意或灵感。

因此，如果你需要记忆知识、需要思考问题、需要回顾学到的材料，一边散步，一边在脑海中整理，是一个非常有效的办法，既运动了身体，又提高了思考效率，一举两得。

当然，一定要注意安全，要选没有车的地方喔。

3. 用发呆让大脑回放记忆

一个可能非常违背直觉的理论是：有时候，让自己发呆，什么也不做，比你去持续不断地学习，效果其实要更好。

2004年，专门研究记忆的心理学家Nelson Cowan做了一项实验。他请两组记忆障碍患者听一个故事，并在一个小时后回答问题。A组患者需要谈话，不断摄取新信息；B组患者则单独待在房间里，什么也不做。结果令人惊讶：A组对故事信息的回忆正确率是7%，而B组则达到了79%——几乎比正常人能做到的成绩还好。

2012年，Cowan又做了一项实验。这次他让两组正常人听一个故事。听完后，A组需要去玩一个游戏，B组什么也不做，保持10分钟。结果发现，B组对故事细节的记忆效果显著高于A组，甚至在实验结束的7天后，这种效应依然存在。

为什么会这样呢？原因在于：当我们睡觉的时候，大脑其实在做一件事情： 对我们今天学到的东西进行“回放”， 把它进行加强巩固。这种回放不仅仅发生在睡觉时，也发生在我们安静休息、什么也不做时。

进一步的神经科学研究也发现：当我们看起来“什么也没做”时，大脑海马体中其实正在发生着高频的放电。这种放电，实际上就是大脑在用数倍到数十倍的速度，在回放我们之前学习到的信息，让它不断强化巩固，加深印象。

也就是说：当我们为了学习更多的东西，而去不断追捧所谓的“长时间专注学习”“把时间利用起来”时，大脑其实是在疲于奔命的：它还没有巩固学到的旧信息，新的信息就进来了。长此以往，结果就只能是：我们学了很多东西，但却什么也没记住。

因此，如果你想提高自己的学习效果，想让大脑变得更清晰、更有序，想摆脱“读了很多的书，但却什么都没记住”的情况——那么你需要的，可能不是“尽量抽出时间”看书、学东西，而是给自己一段什么都不做的时间，让大脑静静地酝酿、整理。

这比任何学习技巧都好用。

4. 先提问，后学习

如果你想快速提高自己的学习效果的话，有一个简单而极其有效的办法： 先提问，再学习。

很多读者问过我：预习究竟有没有用呢？其实，一个违背常识的结论是：在正式上课之前， 通过阅读课程材料来预习，不但没有好处，反而会降低学习效果。

为什么？原因很简单：预习的时候，我们会先把材料过一遍，这时它在我们脑海中会留下一个印象。而正式上课时，由于这个印象的存在，我们会产生一种“熟悉的错觉”：也就是大脑以为自己对它已经熟悉了，但实际上并不熟悉。

这就会导致，大脑会以为它已经是我们熟悉的知识，于是会降低对它的吸收和摄取，减少对它的资源供给，导致我们的学习效果变得更差。

那么，什么才是有效的预习方式呢？2021年一项研究发现：当学生在学习前， 先针对课程内容提出问题时，他们的学习效果会更好。（Sinha&Kapur，2021）

进一步，这种学习效果的提升是跟“提出问题”的深度成正比的。如果你先试着去做一些练习、甚至试着去解决一些问题，再来有针对性地学习，那么学习效果是最好的。

原因很简单：这种“提问式”的学习方法，会激活大脑的警觉系统和预测加工系统，让大脑更好地编码学到的知识，并把它们放在对应的位置，从而更容易将知识巩固和内化。

一个简单的操作是：当你看到一篇感兴趣的文章时，不要直接打开它，而是先问一问：针对这个主题，我都知道什么？我想从中再知道一些别的什么？

同样，当你读书时，看到一个章节、或者作者抛出的一个问题时，不要急着往下读，而是先问一问自己：我会如何解答这个问题？我的看法和观点是什么？

然后，再将自己的思考结果，跟作者讲的内容进行对比。去着重理解两者的不同点，以及为什么会有这些不同点。

这是一个性价比极高的学习技巧。

5. 换个新环境再学习

大脑有两个非常底层的功能：

一是，它善于在事物之间创造联系；

二是，它善于发现事物跟以往不同的地方，对新奇的事物更感兴趣。

有没有发现，将这两个功能结合起来，我们就可以得到一个非常有用的技巧：

当你想学习一些比较重要的知识时，不妨换一个新的环境去学习。

举个例子：比如你天天待在家里，现在想考一个证书，那么更好的做法，不是在家里学习，而是出门，找一个平时没去过或很少去的地方，比如咖啡馆、图书馆、自习室……在里面学习。

为什么？ 因为当你处于一个全新的环境的时候，大脑会被高强度地激活起来。这时，它会更容易将这个“新的环境”跟你所学习的知识之间建立联系，从而把它跟“旧的知识”所区分开来，让你对新知识记得更牢固、更深刻。

甚至，你可以人为地创造一些“新场景”，比如：

不要在一个座位待太久，每几天就换一个位置，高频度刺激大脑；

试着去不同的地点和场所学习，每一个场所学习相似的内容，增强联系；

在特定的日子学习更重要的内容，比如，在大雨倾盆的时候学习更困难的知识，让“坏天气+新场景”成为一个更强的记忆线索……

一个很常见的现象是：当你回忆某个知识点时，你未必能立刻想起来；但一旦你回想起看到这个知识点的场景，比如回想起当时所在的场所、当时的天气、周围的人群、甚至包括听到的声音和嗅到的气味……这个知识就会鲜明地涌现出来。

所以，如果你需要高强度地学习和思考，那么，一定不要长期待在同一个地方，而是不断给大脑新的刺激。

这会让这些新的知识，在你脑海中变得更牢固、更稳定。

6. 用纸笔来辅助思考

经常有人问我：看电子书和记电子笔记，以及看纸质书和用纸笔做笔记，哪种效果更好呢？

这个问题其实有一个简明扼要的回答：任何时候，看纸质书和用纸笔做笔记，效果都是更好的。

为什么呢？原因很简单： 因为纸质书和纸质笔记可以提供更多的记忆线索，让我们把知识更好地联系和巩固起来。

举个例子：比如你读一本书，看到某个很有趣的知识点。那么当你回忆这个知识点时，你可能不记得它具体在这本书的第几页，但你一定会记得它在这本书的“大概什么位置”——是前面、中间还是后面，大概占了多少页，等等。

这种情况，就是这本书本身的物理形态——它的厚度、页码、翻页的手感和记忆等信息综合起来，为你提供了关于这个知识点的更多的线索，帮你牢牢地把它记住。

同样，你用纸笔记下的笔记，也总是会记得更牢，原因就在于：你写字时所调动的脑区和使用的资源，会比打字多得多。这些更多的脑区调用和资源都会提供更多的信息，帮助你将这段记忆更好地巩固起来。

但是，纸质书和纸质笔记确实不太方便储存和整理。因此，我的习惯是：

日常阅读电子书，用笔记软件做笔记。但非常重要或有用的书，我会买一本实体书回来收藏；同样，当我看到一个非常重要的知识点时，我会用笔在纸上把它画下来，理一下它的逻辑脉络，画一下它的结构。

画下来的内容，我会把它拍照储存起来。但其实不储存也没关系。因为画图、梳理这个过程本身，就已经是在训练大脑更好地注意和记忆它了。

这是一个平衡的做法，兼顾了效率和效果，非常方便。

7. 用输出来反哺输入

最后，是一个十分经典的方法： 费曼学习法。

它是我践行了许多年的习惯，也是我学习和整理知识体系的秘诀。

简而言之：当我学到一个自己非常感兴趣的知识点时，我会在心里想象有一个听众，然后用自己的话，把这个知识点掰开了、揉碎了，讲给这个“心里的听众”听。务求让完全零基础的人也能听懂。

基本上，这样讲完一遍，对这个知识点的记忆也就非常深刻了，可以持续非常长的时间。

如果在讲解的过程中发现问题、遇到阻碍，有一些地方不知道该怎么讲，或者无法用自己的话去表述——那么，这就是一个推动你去加深理解的好机会。它正是在告诉你：你对这个知识点的理解还不够深刻，存在这些漏洞需要去弥补。

其实，我的许多文章，也可以看作是一个更高阶的费曼学习法：它们往往都是我在很长一段时间内，对一个主题进行研究、学习、思考和实践的成果。借由写一篇文章，我就能把这些经历汇总整理起来，让它们形成一个牢固的知识结构，嵌入我的知识体系之中。

如果觉得写文章太困难，你可以参考我前面的做法，把它讲给心里的听众。这样会更简单。

但一定要注意“用自己的话”，否则，你就只是在照搬作者的思考而已，并没有真的去消化这些知识点。

一旦你养成了这个习惯，你会发现，你学到的知识，想忘也忘不掉。

提升接口性能的39个方法，两万字总结，太全了！

Mon, 09 Oct 2023 06:55:16 CST

theme: cyanosis

为了更好评估后端接口性能，我们需要对不同行为的耗时进行比较。从上图可以看出，一个CPU周期少于1纳秒，而一次从北京到上海的跨地域访问可能需要约30毫秒。怎么计算跨地域耗时呢？

我们已知光在真空中传播，折射率为 1，其光速约为 c=30 万公里/秒，当光在其他介质里来面传播，其介质折射自率为 n,光在其中的速度就降为 v=c/n，光纤的材料是二氧化硅，其折射率 n 为 1.44 左右，计算延迟的时候，可以近似认为 1.5，我们通过计算可以得出光纤中的光传输速度近似为 v=c/1.5= 20 万公里/秒。

以北京和深圳为例，直线距离 1920 公里，接近 2000 公里，传输介质如果使用光纤光缆，那么延迟时间 t=L/v = 0.2 万公里/20 万公里/秒=10ms ，也就是说从北京到深圳拉一根 2000 公里的光缆，单纯的距离延迟就要 10ms ，实际上是没有这么长的光缆的，中间是需要通过基站来进行中继，并且当光功率损耗到一定值以后，需要通过转换器加强功率以后继续传输，这个中转也是要消耗时间的。另外数据包在网络中长距离传输的时候是会经过多次的封包和拆包，这个也会消耗时间。

综合考虑各种情况以后，以北京到深圳为例，总的公网延迟大约在 40ms 左右，北京到上海的公网延迟大约在 30ms，如果数据出国的话，延迟会更大，比如中国到美国，延迟一般在 150ms ~ 200ms 左右，因为要经过太平洋的海底光缆过去的。

如果让你进行后端接口的优化，你是首选优化代码行数？还是首选避免跨地域访问呢？

在评估接口性能时，我们需要首先找出最耗时的部分，并优化它，这样优化效果才会立竿见影。上图提供了一个很好的参考。

需要注意的是，上图中没有显示机房内网络的耗时。一次机房内网络的延迟（Ping）通常在1毫秒以内，相比跨地域网络延迟要少很多。

对于机房内的访问，Redis缓存的访问耗时通常在1-5毫秒之间，而数据库的主键索引访问耗时在5-15毫秒之间。当然，这两者最大的区别不仅仅在于耗时，而更重要的是它们在承受高并发访问方面的能力。Redis单机可以承受10万并发（往往瓶颈在网络带宽和CPU），而MySQL要考虑主从读写分离和分库分表，才能稳定支持5千并发以上的访问。

1. 优化前端接口

1.1 核心数据和非核心数据拆分为多个接口

我曾经对用户（会员）主页接口进行了优化，该接口返回的数据非常庞大。由于各个模块的数据都在同一个接口中，只要其中一部分数据的查询耗时较长，整体性能就会下降，导致接口的失败率增加，前端无法展示核心数据。这主要是因为核心数据和非核心数据没有进行隔离，耗时数据和非耗时数据没有分开。

对于庞大的接口，我们需要先梳理每个模块中数据的获取逻辑和性能情况，明确前端必须展示和重点关注的核心数据，并确保这些数据能够快速、稳定地响应给前端。而非核心的数据和性能较差的数据则可以拆分到另外的接口中，即使这些接口的失败率较高，对用户影响也不大。

这种优化方式除了能保证快速返回核心数据，也能提高稳定性。如果非核心数据故障，可以单独降级，不会影响核心数据展示，大大提高了稳定性。

1.2 前端并行调用多个接口

后端提供给前端的接口应保证能够独立调用，避免出现需要先调用A接口再调用B接口的情况。如果接口设计不合理，前端需要的总耗时将是A接口耗时与B接口耗时之和。相反，如果接口能够独立调用，总耗时将取决于A接口和B接口中耗时较长的那个。显然，后者的性能更优。

在A接口与B接口都依赖相同的公共数据的情况下，会导致重复查询。为了优化总耗时，重复查询是无法避免的，因此应着重优化公共数据的性能。

在代码设计层面，应封装每个模块的取值逻辑，避免A接口与B接口出现重复代码或拷贝代码的情况。

1.3 使用MD5加密，防篡改数据，减少重复校验

在提单接口中，需要校验用户对应商品的可见性、是否符合优惠活动规则以及是否可用对应的优惠券等内容。由于用户可能篡改报文来伪造提单请求，后端必须进行校验。然而，由于提单链路本身耗时较长，多次校验以上数据将大大增加接口的耗时。那么，是否可以不进行以上内容的校验呢？

是可以的。在用户提单页面，商品数据、优惠活动数据以及优惠券等数据都是预览接口校验过的。后端可以生成一个预览Token，并将预览结果存在缓存中，前端在提单接口中指定预览Token。后端将校验提单数据和预览数据是否一致，如果不一致，则说明用户伪造了请求。

为了避免预览数据占用过多的缓存空间，可以设置一个过期时间，例如预览数据在15分钟内不进行下单操作，则会自动失效。另外，还可以对关键数据进行MD5加密处理，加密后的数据只有64位，数据量大大减少。后端在提单接口中对关键数据进行MD5加密，并与缓存中的MD5值进行比对，如果不一致，则说明用户伪造了提单数据。

更详细请参考 # 如何防止提单数据被篡改？

1.4 同步写接口改为异步写接口

在写接口耗时较高的情况下，可以采取将接口拆分为两步来优化性能。首先，第一步是接收请求并创建一个异步任务，然后将任务交给后端进行处理。第二步是前端轮训异步任务的执行结果，以获取最终结果。

通过将同步接口异步化，可以避免后端线程资源被长时间占用，并且可以避免浏览器和服务器的socket连接被长时间占用，从而提高系统的并发能力和稳定性。

此外，还可以在前端接口设置更长的轮训时间，以有效提高接口的成功率，降低同步接口超时失败的概率，提升系统的性能和用户体验。

1.5 页面静态化

在电商领域，商品详情页和活动详情页通常会有非常高的流量，特别是在秒杀场景或大促场景下，流量会更高。同时，商品详情页通常包含大量的信息，例如商品介绍、商品参数等，导致每次访问商品详情都需要访问后端接口，给后端接口带来很大的压力。

为了解决这个问题，可以考虑将商品详情页中不会变动的部分（如商品介绍、头图、商品参数等）静态化到html文件中，前端浏览器直接访问这些静态文件，而无需访问后端接口。这样做可以极大地减轻商品详情接口的查询压力。

然而，对于未上架的商品详情页、后台管理等页面，仍然需要查询商品详情接口来获取最新的信息。

页面静态化需要先使用模版工具例如Thymeleaf等，将商品详情数据渲染到Html文件，然后使用运维工具（rsync）将html文件同步到各个nginx机器。前端就可以访问对应的商品详情页。

当商品上下架状态变化时，将对应Html文件重新覆盖或置为失效。

1.6 不变资源访问CDN

CDN（内容分发网络）是一种分布式网络架构，它将网站的静态内容缓存在全球各地的服务器上，使用户能够从最近的服务器获取所需内容，从而加速用户访问。这样，用户不需要从原始服务器请求内容，可以减少因网络延迟导致的等待时间，提高用户的访问速度和体验。

通过注入静态Html文件到CDN，可以避免每次用户的请求都访问原始服务器。相反，这些文件会被缓存在CDN的服务器上，因此用户可以直接从离他们最近的服务器获取内容。这种方式可以大大减少因网络延迟导致的潜在用户流失，因为用户能够更快地获取所需的信息。

此外，CDN的使用还可以提高系统在高并发场景下的稳定性。在高并发情况下，原始服务器可能无法承受大量的请求流量，并可能导致系统崩溃或响应变慢。但是，通过将静态Html文件注入到CDN，让CDN来处理部分请求，分担了原始服务器的负载，从而提高了整个系统的稳定性。

通过将商品详情、活动详情等静态Html文件注入到CDN，可以加速用户访问速度，减少用户因网络延迟而流失的可能性，并提高系统在高并发场景下的稳定性。

2. 调用链路优化

调用链路优化重点减少RPC的调用、减少跨地域调用。

2.1 减少跨地域调用

刚才我提到了北京到上海的跨地域调用需要耗费大约30毫秒的时间，这个耗时是相当高的，所以我们应该特别关注调用链路上是否存在跨地域调用的情况。这些跨地域调用包括Rpc调用、Http调用、数据库调用、缓存调用以及MQ调用等等。在整理调用链路的时候，我们还应该标注出跨地域调用的次数，例如跨地域调用数据库可能会出现多次，在链路上我们需要明确标记。我们可以考虑通过降低调用次数来提高性能，因此在设计优化方案时，我们应该特别关注如何减少跨地域调用的次数。

举个例子，在某种情况下，假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。

2.2 单元化架构：不同的用户路由到不同的集群单元

如果主数据库位于北京，那么南方的用户每次写请求就只能通过跨地域访问来完成吗？实际上并非如此。数据库的主库不仅可以存在于一个地域，而是可以在多个地域上部署主数据库。将每个用户归属于最近的地域，该用户的请求都会被路由到所在地域的数据库。这样的部署不仅提升了系统性能，还提高了系统的容灾等级，即使单个机房发生故障也不会影响全网的用户。

这个思想类似于CDN（内容分发网络），它能够将用户请求路由到最近的节点。事实上，由于用户的存储数据已经在该地域的数据库中，用户的请求极少需要切换到其他地域。

为了实现这一点，我们需要一个用户路由服务来提供用户所在地域的查询，并且能够提供高并发的访问。

除了数据库之外，其他的存储中间件（如MQ、Redis等）以及Rpc框架都需要具备单元化架构能力。

当我们无法避免跨地域调用时，我们可以选择整体上跨地域调用次数最少的方案来进行优化。

2.3 微服务拆分过细会导致Rpc调用较多

微服务拆分过细会导致更多的RPC调用，一次简单的请求可能就涉及四五个服务，当访问量非常高时，多出来的三五次Rpc调用会导致接口耗时增加很多。

每个服务都需要处理网络IO，序列化反序列化，服务的GC 也会导致耗时增加，这样算下来一个大服务的性能往往优于5个微服务。

当然服务过于臃肿会降低开发维护效率，也不利于技术升级。微服务过多也有问题，例如增加整体链路耗时、基础架构升级工作量变大、单个需求代码变更的服务更多等弊端。需要你权衡开发效率、线上性能、领域划分等多方面因素。

总之应该极力避免微服务过多的情况。

怎么评估微服务过多呢？我的个人经验是：团队内平均一个人两个服务以上，就是微服务过多了。例如三个人的团队6个服务，5个人的团队10个服务。

2.4 去掉中间商，减少Rpc调用

当整个系统的调用链路中涉及到过多的Rpc调用时，可以通过去除中间服务的方式减少Rpc调用。例如从A服务到E服务的调用链路包含了4次Rpc调用（A->B->C->D->E），而我们可以评估中间的B、C、D三个服务的功能是否冗余，是否只是作为转发服务而没有太多的业务逻辑，如果是的话，我们可以考虑让A服务直接调用E服务，从而避免中间的Rpc调用，减少系统的负担。

总的来说，无论是调用链路过长或是微服务过多，都可能导致过多的Rpc请求，因此可以尝试去除中间的服务来优化系统性能。

2.5 提供Client工具方法处理，而非Rpc调用

如果中间服务有业务逻辑，不能直接移除，可以考虑使用基于Java Client工具方法的服务提供方式，而非Rpc方式。

举例来说，如果存在一个调用链路为A->B->C，其中B服务有自己的业务逻辑。此时B服务可以考虑提供一个Java Client jar包给A服务使用。B服务所依赖的数据可以由A服务提供，这样就减少1次 A 服务到B 服务的Rpc调用。

这样做有一个好处，当A、B都共同依赖相同的数据，A服务查询一遍就可以提供给自己和B服务Client使用。如果基于Rpc方式，A、B都需要查询一遍。微服务过多也不好啊！

通过改变服务提供方式，尽量减少Rpc调用次数和开销，从而优化整个系统的性能。

例如社交关注关系服务。在这个服务中，需要查询用户之间的关注关系。为了提高服务性能，关注服务内部使用缓存来存储关注关系。为了降低高并发场景下的调用延迟和机器负载，关注服务提供了一个Java Client Jar查询关注关系，放弃了上游调用rpc接口的方式。这样做的好处是可以减少一次Rpc调用，避免了下游服务因GC 停顿而导致的耗时。

2.6 单条调用改为批量调用

无论是查询还是写入，都可以使用批量调用来代替单条调用。比如，在查询用户订单的详情时，应该批量查询多个订单，而不是通过循环逐个查询订单详情。批量调用虽然会比单条调用稍微耗时多一些，但是循环调用的耗时却是单条调用的N倍，所以批量查询耗时要低很多。

在接口设计和代码流程中，我们应该尽量避免使用for循环进行单条查询或单条写入操作。正如此文所提到的，批量插入数据库的性能可能是单条插入的3-5倍。 # 10亿数据如何插入Mysql，10连问，你想到了几个？

2.7 并行调用

在调用多个接口时，可以选择串行调用或并行调用的两种方式。串行调用是指依次调用每个接口，一个接口完成后才能调用下一个接口，而并行调用是指同时调用多个接口。可以看出并行调用的耗时更低，因为串行调用的耗时是多个接口耗时的总和，而并行调用的耗时是耗时最高的接口耗时。

为了灵活实现多个接口的调用顺序和依赖关系，可以使用Java中的 CompletableFuture类。 CompletableFuture可以将多个接口的调用任务编排成一个有序的执行流程，可以实现最大程度的并发查询或并发修改。

例如，可以并行调用两个接口，然后等待两个接口全部成功后，再对查询结果进行汇总处理。这样可以提高查询或修改的效率。

  CompletableFuture<Void> first = CompletableFuture.runAsync(()->{  
            System.out.println("do something first");
            Thread.sleep(200);
        });  
        CompletableFuture<Void> second = CompletableFuture.runAsync(() -> {  
            System.out.println("do something second");  
            Thread.sleep(300);
        });  
        CompletableFuture<Void> allOfFuture = CompletableFuture.allOf(first, second).whenComplete((m,k)->{  
            System.out.println("all finish do something");
        });
        
        allOfFuture.get();//汇总处理结果

CompletaleFuture 还支持自定义线程池，支持同步调用、异步调用，支持anyOf任一成功则返回等多种编排策略。由于不是本文重点，不再一一说明

2.8 提前过滤，减少无效调用

在某些活动匹配的业务场景里，相当多的请求实际上是不满足条件的，如果能尽早的过滤掉这些请求，就能避免很多无效查询。例如用户匹配某个活动时，会有非常多的过滤条件，如果该活动的特点是仅少量用户可参加，那么可首先使用人群先过滤掉大部分不符合条件的用户。

2.9 拆分接口

前面提到如果Http接口功能过于庞大，核心数据和非核心数据杂糅在一起，耗时高和耗时低的数据耦合在一起。为了优化请求的耗时，可以通过拆分接口，将核心数据和非核心数据分别处理，从而提高接口的性能。

而在Rpc接口方面，也可以使用类似的思路进行优化。当上游需要调用多个Rpc接口时，可以并行地调用这些接口。优先返回核心数据，如果处理非核心数据或者耗时高的数据超时，则直接降级，只返回核心数据。这种方式可以提高接口的响应速度和效率，减少不必要的等待时间。

3. 选择合适的存储系统

无论是查询接口还是写入接口都需要访问数据源，访问存储系统。读高写低，读低写高，读写双高等不同场景需要选择不同的存储系统。

3.1 MySQL 换 Redis

当系统查询压力增加时，可以把MySQL数据异构到Redis缓存中。

3.1.1 选择合适的缓存结构

Redis包含了一些常见的数据结构，包括字符串（String）、列表（List）、有序集合（SortSet）、哈希（Hash）和基数估计（HyperLogLog）、GEOHash等。

在不同的应用场景下，我们可以根据需求选择合适的数据结构来存储数据。举例来说，如果我们需要存储用户的关注列表，可以选择使用哈希结构（Hash）。对于需要对商品或文章的浏览量进行去重的情况，可以考虑使用基数估计结构（HyperLogLog）。而对于用户的浏览记录，可以选择列表（List）等结构来存储。如果想实现附近的人功能，可以使用Redis GEOHash结构。

Redis提供了丰富的API来操作这些数据结构，我们可以根据实际需要选择适合的数据结构和相关API来简化代码实现，提高开发效率。

关于缓存结构选择可以参考这篇文章。 # 10W+TPS高并发场景【我的浏览记录】系统设计

3.1.2 选择合适的缓存策略

缓存策略指的是何时更新缓存和何时将缓存标记为过期或清理缓存。主要有两种策略。

策略1：是当数据更新时，更新缓存，并且在缓存Miss（即缓存中没有所需数据）时，从数据源加载数据到缓存中。

策略2：是将缓存设置为常驻缓存，即缓存永远不过期。当数据更新时，会即时更新缓存中的数据。这种策略通常会占用大量内存空间，因此一般只适用于数据量较小的情况下使用。另外，定时任务会定期将数据库中的数据更新到缓存中，以兜底缓存数据的一致性。

总的来说，选择何种缓存策略取决于具体的应用需求和数据规模。如果数据量较大，一般会选择策略1；而如果数据量较小且要求缓存数据的实时性，可以考虑策略2。

关于缓存使用，可以参考我的踩坑记录： #点击这里了解第一次使用缓存翻车了

3.2 Redis 换本地缓存

Redis相比传统数据库更快且具有更强的抗并发能力。然而，与本地缓存相比，Redis缓存仍然较慢。前面提到的Redis访问速度大约在3-5毫秒之间，而使用本地缓存几乎可以忽略不计。

如果频繁访问Redis获取大量数据，将会导致大量的序列化和反序列化操作，这会显著增加young gc频率，也会增加CPU负载。

本地缓存的性能更强，当使用Redis仍然存在性能瓶颈时，可以考虑使用本地缓存。可以设置多级缓存机制，首先访问本地缓存，如果本地缓存中没有数据，则访问Redis分布式缓存，如果仍然不存在，则访问数据库。通过使用多级缓存策略来实现更高效的性能。

本地缓存可以使用Guava Cahce 。参考本地缓存框架Guava Cache

也可以使用性能更强的Caffeine。点击这里了解

Redis由于单线程架构，在热点缓存应对上稍显不足。使用本地缓存可以极大的解决缓存热点问题。例如以下代码创建了Caffeine缓存，最大长度1W，写入后30分钟过期，同时指定自动回源取值策略。

  public LoadingCache<String, User> createUserCache() {
    return Caffeine.newBuilder()
            .initialCapacity(1000)
            .maximumSize(10000L)
            .expireAfterWrite(30L, TimeUnit.MINUTES)
            //.concurrencyLevel(8)
            .recordStats()
            .build(key -> userDao.getUser(key));
}

3.3 Redis 换 Memcached

当存在热点key和大key时，Redis集群的负载会变得不均衡，从而降低整个集群的性能。这是因为Redis是单线程执行的系统，当处理热点key和大key时，会对整个集群的性能产生影响。

相比之下，Memcached缓存是多线程执行的，它可以更好地处理热点key和大key的问题，因此可以更好地应对上述性能问题。如果遇到这些问题，可以考虑使用Memcached进行替代。

另外，还可以通过使用本地缓存并结合Redis来处理热点key和热点大key的情况。这样可以减轻Redis集群的负担，并提升系统的性能。

3.4 MySQL 换 ElasticSearch

在后台管理页面中，通常需要对列表页进行多条件检索。MySQL 无法满足多条件检索的需求，原因有两点。第一点是，拼接条件检索的查询SQL非常复杂且需要进行定制化，难以进行维护和管理。第二点是，条件检索的查询场景非常灵活，很难设计合适的索引来提高查询性能，并且难以保证查询能够命中索引。

相比之下，ElasticSearch是一种天然适合于条件检索场景的解决方案。无论数据量的大小，对于列表页查询和检索等场景，推荐首选ElasticSearch。

可以将多个表的数据异构到ElasticSearch中建立宽表，并在数据更新时同步更新索引。在进行检索时，可以直接从ElasticSearch中获取数据，无需再查询数据库，提高了检索性能。

3.5 MySQL 换 HBase

MySQL并不适合大数据量存储，若不对数据进行归档，数据库会一直膨胀，从而降低查询和写入的性能。针对大数据量的读写需求，可以考虑以下方法来存储订单数据。

首先，将最近1年的订单数据存储在MySQL数据库中。这样可以保证较高的数据库查询性能，因为MySQL对于相对较小的数据集来说是非常高效的。

其次，将1年以上的历史订单数据进行归档，并将这些数据异构（转储）到HBase中。HBase是一种分布式的NoSQL数据库，可以存储海量数据，并提供快速的读取能力。

在订单查询接口上，可以区分近期数据和历史数据，使得上游系统能够根据自身的需求调用适当的订单接口来查询订单详情。

在将历史订单数据存储到HBase时，可以设置合理的RowKey。RowKey是HBase中数据的唯一标识，在查询过程中可以通过RowKey来快速找到目标数据。通过合理地设置RowKey，可以进一步提高HBase的查询性能。

通过将订单数据分别存储在MySQL和HBase中，并根据需求进行区分查询，可以满足大数据量场景的读写需求。MySQL用于存储近期数据，以保证查询性能；而HBase用于存储归档的历史数据，并通过合理设置的RowKey来提高查询性能。

4.代码层次优化

4.1 同步转异步

将写请求从同步转为异步可以显著提升接口的性能。

以发送短信接口为例，该接口需要调用运营商接口并在公网上进行调用，因此耗时较高。如果业务方选择完全同步发送短信，就需要处理失败、超时、重试等与稳定性有关的问题，且耗时也会非常高。因此，我们需要采用同步加异步的处理方式。

公司的短信平台应该采用Rpc接口发送短信。在收到请求后，首先进行校验，包括校验业务方短信模板的合法性以及短信参数是否合法。待校验完成后，我们可以将短信发送任务存入数据库，并通过消息队列进行异步处理。而对业务方提供的Rpc接口的语义也发生了变化：我们成功接收了发送短信的请求，稍后将以异步的方式进行发送。至于发送短信失败、重试、超时等与稳定性和可靠性有关的问题，将由短信平台保证。而业务方只需确保成功调用短信平台的Rpc接口即可

4.2 减少日志打印

在高并发的查询场景下，打印日志可能导致接口性能下降的问题。我曾经不认为这会是一个问题，直到我的同事犯了这个错误。有同事在排查问题时顺手打印了日志并且带上线。第二天高峰期，发现接口的 tp99 耗时大幅增加，同时 CPU 负载和垃圾回收频率也明显增加，磁盘负载也增加很多。日志删除后，系统回归正常。

特别是在日志中包含了大数组或大对象时，更要谨慎，避免打印这些日志。

4.3 使用白名单打印日志

不打日志，无法有效排查问题。怎么办呢？

为了有效地排查问题，建议引入白名单机制。具体做法是，在打印日志之前，先判断用户是否在白名单中，如果不在，则不打印日志；如果在，则打印日志。通过将公司内的产品、开发和测试人员等相关同事加入到白名单中，有利于及时发现线上问题。当用户提出投诉时，也可以将相关用户添加到白名单，并要求他们重新操作以复现问题。

这种方法既满足了问题排查的需求，又避免了给线上环境增加压力。（在测试环境中，可以完全开放日志打印功能）

4.4 避免一次性查询过多数据

在进行查询操作时，应尽量将单次调用改为批量查询或分页查询。不论是批量查询还是分页查询，都应注意避免一次性查询过多数据，比如每次加载10000条记录。因为过大的网络报文会降低查询性能，并且Java虚拟机（JVM）倾向于在老年代申请大对象。当访问量过高时，频繁申请大对象会增加Full GC（垃圾回收）的频率，从而降低服务的性能。

建议最好支持动态配置批量查询的数量。当接口的性能较差时，可以通过动态配置批量查询的数量来优化接口的性能，根据实际情况灵活地调整每次查询的数量。

4.5 避免深度分页

深度分页指的是对一个大数据集进行分页查询时，每次只查询一页的数据，但是要获取到指定页数的数据，就需要依次查询前面的页数，这样查询的范围就会越来越大，导致查询效率变低。

在进行深度分页时，MySQL和ElasticSearch会先加载大量的数据，然后根据分页要求返回少量的数据。这种处理方式导致深度分页的效率非常低，同时也给MySQL和ElasticSearch带来较高的内存压力和CPU负载。因此，我们应该尽可能地避免使用深度分页的方式。

为了避免深度分页，可以采用每次查询时指定最小id或最大id的方法。具体来说，当进行分页查询时，可以记录上一次查询结果中的最小id或最大id（根据排序方式来决定）。在进行下一次查询时，指定查询结果中的最小id或最大id作为起始条件，从而缩短查询范围。这样每次只获取前N条数据，可以提高查询效率。

关于分页可以参考我的文章 # 四选一，如何选择适合你的分页方案？

4.6 只访问需要用到的数据

为了查询数据库和下游接口所需的字段，我们可以采取一些方法。例如，商品数据的字段非常多，如果每次调用都返回全部字段，将导致数据量过大。因此，上游可以指定使用的字段，从而有效降低接口的数据量，提升接口的性能。

这种方式不仅可以减少网络IO的耗时，而且还可以减少Rpc序列化和反序列化的耗时，因为接口的数据量较少。

对于访问量极大的接口来说，处理这些多余的字段将会增加CPU的负载，并增加Young GC的次数。因此不要把所有的字段都返回给上游！应该按需定制。

4.7 预热低流量接口

对于访问量较低的接口来说，通常首次接口的响应时间较长。原因是JVM需要加载类、Spring Aop首次动态代理，以及新建连接等。这使得首次接口请求时间明显比后续请求耗时长。

然而在流量较低的接口中，这种影响会更大。用户可能尝试多次请求，但依然经常出现超时，严重影响了用户体验。每次服务发布完成后，接口超时失败率都会大量上升！

那么如何解决接口预热的问题呢？可以考虑在服务启动时，自行调用一次接口。如果是写接口，还可以尝试更新特定的一条数据。

另外，可以在服务启动时手动加载对应的类，以减少首次调用的耗时。不同的接口预热方式有所不同，建议使用阿里开源的诊断工具arthas，通过监控首次请求时方法调用堆栈的耗时来进行接口的预热。

arthas使用文档 https://arthas.aliyun.com/doc/trace.html

使用arthas trace命令可以查看某个方法执行的耗时情况。 trace com.xxxx.ClassA function1

5. 数据库优化

5.1 读写分离

增加MySQL数据库的从节点来实现负载均衡，减轻主节点的查询压力，让主节点专注于处理写请求，保证读写操作的高性能。

除此之外，当需要跨地域进行数据库的查询时，由于较高网络延迟等问题，接口性能可能变得很差。在数据实时性不太敏感的情况下，可以通过在多个地域增加从节点来提高这些地域的接口性能。举个例子，如果数据库主节点在北京，可以在广州、上海等地区设置从节点，在数据实时性要求较低的查询场景，可有效提高南方地区的接口性能。

5.2 索引优化

5.2.1查询更新务必命中索引

查询和更新SQL必须命中索引。查询SQL如果没命中索引，在访问量较大时，会出现大量慢查询，严重时会导致整个MySQL集群雪崩，影响到其他表、其他数据库。所以一定要严格审查SQL是否命中索引。可以使用explain命令查看索引使用情况。

在SQL更新场景，MySQL会在索引上加锁，如果没有命中索引会对全表加锁，全表的更新操作都会被阻塞住。所以更新SQL更要确保命中索引。

因此，为了避免这种情况的发生，需要严格审查SQL是否命中索引。可以使用"explain"命令来查看SQL的执行计划，从而判断是否有使用索引。这样可以及早发现潜在的问题，并及时采取措施进行优化和调整。

除此之外，最好索引字段能够完全覆盖查询需要的字段。MySQL索引分主键索引和普通索引。普通索引命中后，往往需要再查询主键索引获取记录的全部字段。如果索引字段完全包含查询的字段，即索引覆盖查询，就无需再回查主键索引，可以有效提高查询性能。

更详细请参考本篇文章 # 深入理解mysql 索引特性

5.2.2 常见索引失效的场景

查询表达式索引项上有函数.例如 date(created_at) = 'XXXX'等.字符处理等。mysql将无法使用相应索引
一次查询（简单查询，子查询不算）只能使用一个索引
！= 不等于无法使用索引
未遵循最左前缀匹配导致索引失效
类型转换导致索引失效，例如字符串类型指定为数字类型等。
like模糊匹配以通配符开头导致索引失效
索引字段使用is not null导致失效
查询条件存在 OR，且无法命中索引。

5.2.3 提高索引利用率

当索引数量过多时，索引的数据量就会增加，这可能导致数据库无法将所有的索引数据加载到内存中，从而使得查询索引时需要从磁盘读取数据，进而大大降低索引查询的性能。举例来说，我们组有张表700万条数据，共4个索引，索引数据量就达到2.8GB。在一个数据库中通常有多张表，在进行分库分表时，可能会存在100张表。100张表就会产生280GB的索引数据，这么庞大的数据量无法全部放入内存，查询索引时会大大降低缓存命中率，进而降低查询和写入操作的性能。简而言之，避免创建过多的索引。

可以选择最通用的查询字段作为联合索引最左前缀，让索引覆盖更多的查询场景。

5.3 事务和锁优化

为了提高接口并发量，需要避免大事务。当需要更新多条数据时，避免一次性更新过多的数据。因为update，delete语句会对索引加锁，如果更新的记录数过多，会锁住太多的数据，由于执行时间较长，会严重限制数据库的并发量。

间隙锁是MySQL在执行更新时为了保证数据一致性而添加的锁定机制。虽然更新的记录数量很少，但MySQL可能会锁定比更新数量更大的范围。因此，需要注意查询语句中的where条件是否包含了较大的范围，这样可能会锁定不应该被锁定的记录。

如果有批量更新的情况，需要降低批量更新的数量，缩小更新的范围。

其次在事务内可能有多条SQL，例如扣减库存和新增库存扣减流水有两条SQL。因为两个SQl在同一个事务内，所以可以保证原子性。但是需要考虑两个SQL谁先执行，谁后执行？

建议先扣库存，再增加流水。

扣减库存的更新操作耗时较长且使用了行锁，而新增流水的速度较快但是串行执行，如果先新增流水再扣减库存，会导致流水表被锁定的时间更长，限制了流水表的插入速度，同时会阻塞其他扣减库存的事务。相反，如果先扣减库存再新增流水，流水表被锁定的时间较短，有利于提高库存扣减的并发度。

5.4 分库分表，降低单表规模

MySQL单库单表的性能瓶颈很容易达到。当数据量增加到一定程度时，查询和写入操作可能会变得缓慢。这是因为MySQL的B+树索引结构在单表行数超过2000万时会达到4层，同时索引的数据规模也会变得非常庞大。如果无法将所有索引数据都放入内存缓存中，那么查询索引时就需要进行磁盘查询。这会导致查询性能下降。参考 # 10亿数据如何插入Mysql，10连问，你想到了几个？

为了克服这个问题，系统设计在最初阶段就应该预测数据量，并设置适合的分库分表策略。通过将数据分散存储在多个库和表中，可以有效提高数据库的读写性能。此外，分库分表也可以突破单表的容量限制。

分库分表工具推荐使用 Sharding-JDBC

5.5 冗余数据，提高查询性能

使用分库分表后，索引的使用受到限制。例如，在关注服务中，需要满足两个查询需求：1. 查询用户的关注列表；2. 查询用户的粉丝列表。关注关系表包含两个字段，即关注者的fromUserId和被关注者的toUserId。

对于查询1，我们可以指定 fromUserId = A，即可查询用户A的关注列表。

对于查询2，我们可以指定 toUserId = B，即可查询用户B的粉丝列表。

在单库单表的情况下，我们可以设计fromUserId和toUserId这两个字段作为索引。然而，当进行分库分表后，我们面临选择哪个字段作为分表键的困扰。无论我们选择使用fromUserId还是toUserId作为分表键，都会导致另一个查询场景变得难以实现。

解决这个问题的思路是：存储结构不仅要方便写入，还要方便查询。既然查询不方便，我们可以冗余一份数据，以便于查询。我们可以设计两张表，即关注列表表（Follows）和粉丝列表表（Fans）。其中，Follows表使用fromUserId作为分表键，用于查询用户的关注列表；Fans表使用toUserId作为分表键，用于查询用户的粉丝列表。

通过冗余更多的数据，我们可以提高查询性能，这是常见的优化方案。除了引入新的表外，还可以在表中冗余其他表的字段，以减少关联查询的次数。

关注关系设计请参考 #解密亿级流量【社交关注关系】系统设计

5.6 归档历史数据，降低单表规模

MySQL并不适合存储大数据量，如果不对数据进行归档，数据库会持续膨胀，从而降低查询和写入的性能。为了满足大数据量的读写需求，需要定期对数据库进行归档。

在进行数据库设计时，需要事先考虑到对数据归档的需求，为了提高归档效率，可以使用ctime（创建时间）进行归档，例如归档一年前的数据。

可以通过以下SQL语句不断执行来归档过期数据：

delete from order where ctime < ${minCtime} order by ctime limit 100;

需要注意的是， 执行delete操作时，ctime字段应该有索引，否则将会锁住整个表！

另外，在将数据库数据归档之前，如果有必要，一定要将数据同步到Hive中，这样以后如果需要进行统计查询，可以使用Hive中的数据。如果归档的数据还需要在线查询，可以将过期数据同步到HBase中，这样数据库可以提供近期数据的查询，而 HBase可以提供历史数据的查询。可参考上述 MySQL转HBase的内容。

5.7 使用更强的物理机 CPU/内存/SSD硬盘

MySQL的性能取决于内存大小、CPU核数和SSD硬盘读写性能。为了适配更强的宿主机，可以进行以下MySQL优化配置

innodb_buffer_pool_size

缓冲池是数据和索引缓存的地方。默认大小为128M。这个值越大越好决于CPU的架构，这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存)，20-25GB(32GB内存)，100-120GB(128GB内存)。

max_connections

数据库最大连接数。可以适当调大数据库链接

innodb_flush_log_at_trx_commit

控制MySQL刷新数据到磁盘的策略。

默认=1，即每次事务提交都会刷新数据到磁盘，安全性最高不会丢失数据。
当配置为0、2 会每隔1s刷新数据到磁盘，在系统宕机、 mysql crash时可能丢失1s的数据。

innodb_thread_concurrency

innodb_thread_concurrency默认是0，则表示没有并发线程数限制，所有请求都会直接请求线程执行。

当并发用户线程数量小于64，建议设置innodb_thread_concurrency=0；在大多数情况下，最佳的值是小于并接近虚拟CPU的个数；

innodb_read_io_threads

设置InnoDB存储引擎的读取线程数。默认值是4，表示使用4个线程来读取数据。可以根据服务器的CPU核心数来调整这个值。例如调整到16甚至32。

innodb_io_capacity

innodb_io_capacity InnoDB可用的总I/O容量。该参数应该设置为系统每秒可以执行的I/O操作数。该值取决于系统配置。当设置 innodb_io_capacity时，主线程会根据设置的值来估算后台任务可用的I/O带宽

innodb_io_capacity_max: 如果刷新操作过于落后，InnoDB可以超过 innodb_io_capacity的限制进行刷新，但是不能超过本参数的值

默认情况下，MySQL 分别配置了200 和2000的默认值。

当磁盘为SSD时，可以考虑设置 innodb_io_capacity= 2000，innodb_io_capacity_max=4000。

6. 压缩数据

6.1 压缩数据库和缓存数据

压缩文本数据可以有效地减少该数据所需的存储空间，从而提高数据库和缓存的空间利用率。然而，压缩和解压缩的过程会增加CPU的负载，因此需要仔细考虑是否有必要进行数据压缩。此外，还需要评估压缩后数据的效果，即压缩对数据的影响如何。

例如下面这一段文字我们使用 GZIP 进行压缩

假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。

该段文字使用UTF-8编码，共570位byte。使用GZIP 压缩后，变为328位Byte。压缩效果还是很明显的。

压缩代码如下

  //压缩
public static byte[] compress(String str, String encoding) {
   if (str == null || str.length() == 0) {
      return null;
   }
   byte[] values = null;
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   GZIPOutputStream gzip;
   try {
      gzip = new GZIPOutputStream(out);
      gzip.write(str.getBytes(encoding));
      gzip.close();
      values = out.toByteArray();
      out.close();
   } catch (IOException e) {
      log.error("gzip compress error.", e);
      throw new RuntimeException("压缩失败", e);
   }
   return values;
}
// 解压缩
public static String uncompressToString(byte[] bytes, String encoding) {
   if (bytes == null || bytes.length == 0) {
      return null;
   }
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   ByteArrayInputStream in = new ByteArrayInputStream(bytes);
   try {
      GZIPInputStream ungzip = new GZIPInputStream(in);
      byte[] buffer = new byte[256];
      int n;
      while ((n = ungzip.read(buffer)) >= 0) {
         out.write(buffer, 0, n);
      }
      String value = out.toString(encoding);
      out.close();
      return value;
   } catch (IOException e) {
      log.error("gzip uncompress to string error.", e);
      throw new RuntimeException("解压缩失败", e);
   }
}

值得一提的是使用 GZIP压缩算法的cpu负载和耗时都是比较高的。使用压缩非但不能起到降低接口耗时的效果，可能导致接口耗时增加，要谨慎使用。除此之外，还有其他压缩算法在压缩时间和压缩率上有所权衡。可以选择适合的自己的压缩算法。

7. 系统优化

7.1 优化GC

无论是Young GC还是Full GC，在进行垃圾回收时都会暂停所有的业务线程。因此，需要关注垃圾回收的频率，以确保对业务的影响尽可能小。

插播提问：为什么young gc也需要stop the world ？ 阿里面试官问我的，把我问懵逼了。

一般情况下，通过调整堆大小和新生代大小可以解决大部分垃圾回收问题。其中，新生代是用于存放新创建的对象的区域。对于Young GC的频率增加的情况，一般是系统的请求量大量增长导致。但如果young gc增长非常多，就需要考虑是否需要增加新生代的大小。

因为如果新生代过小，很容易被打满。这导致本可以被Young GC掉的对象被晋升（Promotion）到老年代，过早地进入老年代。这样一来，不仅Young GC频繁触发，Full GC也会频繁触发。

gc场景非常多，建议参考美团的技术文章详细概括了9种CMS GC问题。# Java中9种常见的CMS GC问题分析与解决

7.2 提升服务器硬件

如果cpu负载较高可以考虑提高每个实例cpu数量，提高实例个数。同时关注网络IO负载，如果机器流量较大，网卡带宽可能成为瓶颈。

高峰期和低峰期如果机器负载相差较大，可以考虑设置弹性伸缩策略，高峰期之前自动扩容，低峰期自动缩容，最大程度提高资源利用率。

8. 交互优化

8.1 调整交互顺序

我曾经负责过B端商品数据创建，当时产品提到创建完虚拟商品后要立即跳转到商品列表页。当时我们使用ElasticSearch 实现后台管理页面的商品查询，但是ElasticSearch 在新增记录时，默认是每 1 秒钟构建1次索引，所以如果创建完商品立即跳转到商品列表页是无法查到刚创建的商品的。于是和产品沟通商品创建完成跳转到商品详情页是否可以，沟通后产品也认可这个交互。

于是我无需调整ElasticSearch 构建索引的时机。（后来了解到 ElasticSearch 提供了API。新增记录后，可立即构建索引，就不存在1秒的延迟了。但是这样操作索引文件会非常多，影响索引查询性能，不过后台管理对性能要求不高，也能接收。）

通过和产品沟通交互和业务逻辑，有时候能解决很棘手的技术问题。 有困难，不要闷头自己扛哦~

8.2 限制用户行为

在社交类产品中用户关注功能。如果不限制用户可以关注的人数，可能会出现恶意用户大量关注其他用户的情况，导致系统设计变得复杂。

为了判断用户A是否关注用户B，可以查看A的关注列表中是否包含B，而不是检查B的粉丝列表中是否包含A。这是因为粉丝列表的数量可能非常庞大，可能达到上千万。而正常用户的关注列表通常不会很多，一般只有几百到几千人。

为了提高关注关系的查询性能，可将关注列表数据导入到Redis Hash结构中。系统通过限制用户的最大关注上限，避免出现Redis大key的情况，也避免大key过期时的性能问题，保证集群的整体性能的稳定。避免恶意用户攻击系统。

可以看这篇文章详细了解关注系统设计。 # 解密亿级流量【社交关注关系】系统设计

贝叶斯主义投资高手的方法，可以总结为三类

Mon, 10 Jul 2023 23:54:10 CST

来源：思想钢印

投资分析的尽头是贝叶斯概率。

一、同一件事的多个概率

你研究了一家公司的财报，觉得数据很不错，行业空间也很大，有产业政策扶持，投资逻辑也非常顺，你考虑买入；

但你在调研中认识了一个公司离职人员，了解到公司管理混乱，领导人缺乏进取心，在这个竞争非常激烈的行业，你联想到公司的竞争地位实际上是在慢慢下降的，于是你犹豫了；

然后你走访了经销商，发现公司对渠道的控制力很强，而经销商的反馈也表明，消费者很有粘性，近期的动销继续保持强势。

你又跟同行讨论了一番，得到的信息更混乱了……

以上的情况是投资中的常态，从不同角度得到不同的分析结果，对应着不同获胜概率。

但操作上只有“买、不买”两种选择，如果买了，结果只有“达到盈利预期”和“没达到盈利预期”这两种中的一个，为什么一件事会有不同的概率呢？

这取决于你如何理解“概率”。

有人认为，没有什么概率，投资的结果不是赚就是亏，不是0就是100%；也有人认为，投资中有概率但算不出来，等于没有概率。

关于概率，有两种解释，“古典解释”把概率看成是一个客观的独立数值，比如：

已知口袋里有9个红球和1个白球，让你闭着眼睛摸出一个为红球的概率是90%。

如果此时，你看了一眼手上的球，扔掉，继续闭眼再摸一个，因为我不知道你刚才摸到的是什么球，所以我只能认为，你摸到红球的概率还是90%，但因为你知道你自己丢掉的是红球，对于你而言，下一个仍然为红球的概率就变成88.89%。

同一件事就这样出现了两个概率。

这就是概率的另一种解释——贝叶斯概率，这是一个基于信念的、主观的、可变的数值，随着你了解的新信息而变化。

贝叶斯算法的角度看，概率不但可计算，而且可以随着信息变化，而股价的变化取决于信息的边际变化，那么概率的变化也可以引发股价的变化，即，可以用于投资决策。

看一个实际投资问题：有一家大公司搞借壳上市，有A、B、C公司三个备选目标，你在研究了一番后觉得都差不多，于是选择了A。

后来，你找到了一个了解借壳内情的人，告诉他你买了A，但他不愿意直接告诉你答案，只能告诉你，B公司是不可能的。

请问，这个信息对你有用吗？换句话说，现在只剩下A和C两家公司，你要不要把A换成C？

很多同学可能已经看出来了，这就是“三门问题”的变形。

二、三门问题与贝叶斯算法

考虑到还有很多读者不知道“三门问题”，所以我简要地复述一下：

这是一个竞猜的电视节目，台上有三扇关着的门，其中两扇门后是羊，一扇门后是车，你可以选其中任何一扇，如果是车，就归你了。

于是，你随机选了一扇（假设是A）。

按规则，主持人（知道哪扇门后面有车）打开了其中一扇门（假设是B），让你看到这扇门背后是羊，并给你一个机会，你可换一扇门（即从A换成C）。

你的选择是“换”还是“不换”呢？

这个问题的答案，直觉判断“换”与“不换”的概率都是一样的，但实际上，你应该换，换了后得到车的概率更高。

三门问题的标准解释是这样的：因为有两只羊，一台车，所以你一开始选中羊的概率是2/3，选中车的概率是1/3。主持人打开一扇门后，如果你换的话，你之前选的是羊，必然会变成车，之前选的是车，必然变成了羊，概率就完全互换了。变成“2/3的概率选中车，1/3的概率选中羊”。

如果文字还是不好理解，用图会清楚一些：

还是想不通的人，可以用一副扑克牌模拟一下。

三门问题的答案就是重组问题的答案，你现在把仓位从A移到C的话，押中的概率就从33%上升到了67%。

很神奇吧，只要有一条有关的新消息，哪怕与A、C公司都无关，也能改变你现在的概率。

我们再把上面的条件改一改，那位知情人士又说，当然，重组没有结束前，任何事都有可能发生，B也没有完全出局，只是可能性比较低。

根据我们前面分析的方法，把仓位从A移到C的话，并不会上升到66%，但因为B的概率低于33%，换的结果仍然比不换好。

我们把上面的例子从“内幕交易”扩大到正常的投资决策场景。

一支股票，如果你不研究，买入后实现预期收益的概率就是50%。

随着你研究的深入——不管基本面分析还是技术分析还是高手指点，甚至你只是去研究了其他的公司，每掌握一个新信息，就相当于有一个无所不知的主持人帮你关上一扇“门”，买入后实现预期收益的概率开始改变，从50%向上或向下变化。

如果用计算机语言去描述一个投资高手研究决策的过程，必然是上面描述的那样，这被称为“贝叶斯算法”。

贝叶斯算法是人工智能的基础，你问ChatGPT一个问题，它蹦出来的每一个字，都是贝叶斯算法计算的最大概率值对应的字。当你告诉它，刚才说的不对，补充了一个新的信息，它马上就把这个新信息代入到刚才的结果中，产生出新的一串概率最高的文字结果——这回正是你要的答案。

看到这里，很多人就算理解了，也不知道为什么会变成这样，它太违背直觉了。这也是概率的最大特点——它可以被计算，但是你很难感受。

所以，想要理解概率，最好的方法还是“算”——找一个生活中的例子，亲手用贝叶斯公式算一算。

贝叶斯计算是有数字公式的（谢尔顿写在黑板的那个），为了不把大家吓跑，我用一个图形界面去展示，保证不出现任何中学以上的数字公式。

三、贝叶斯计算的图形界面

一位顾客走进商店，看了看货架，向你询问了某商品的情况，请问：这个顾客最终买单的概率有多高？

对于一位销售老手而言，这个问题相当于基本面高手看财报，技术高手看图，可以通过顾客的一举一动，判断客户的成交概率，决定花多少时间去向客户推销，选相应的推销重点，并且决定给出多大的折扣把客户拿下。

回答之前先要知道一个“先验概率”——销售转化率，即“成交客户/所有进来的人”，这是一个历史经验值，任何销售员都应该知道，假设这家店是20%。

下面这张图把所有进店的人分成两部分，左边为成交的20%部分，右边为不成交的80%。

接下来，我们需要在先验概率的基础上，考虑一个新消息——“向你仔细询问了某商品的情况”。

这时，我们需要知道关于这个新信息的两个“条件概率”：成交客户的询问率和未成交客户的询问率——这也是历史经验值，即过去所有成交/不成交的客户中，有过仔细询问行为客户的各自占比，有经验的销售，内心对这两个概率也应该有大致的估计。

先看成交客户的询问率，即“仔细询问的成交客户/所有成交客户”，假设为50%，即把左半边五五开，然后得到上面咨询的成交客户，总占比20%*50%=10%；

再看未成交客户的询问率，即“仔细询问的未成交客户/所有未成交客户”，假设为30%，把右半边三七开，上面咨询的未成交客户，总占比80%*30%=24%。

上图的四个角分别代表了四种情况，我们今天遇到的是上半部分——咨询客户，所以，首先把下半部分的情况去掉，只看上半部分。

我们现在要分析的是——仔细咨询且成交的客户，占所有成交客户的比重，很明显，就是左上角占上半部分的比例：

结果，在咨询客户中，最终成交的概率为：10%/（10%+24%）=29.4%。

所以，一位走进商场的客户，当他开口咨询时，他的成交概率就从20%上升至29.4%，有经验的销售员就应该注意这条销售线索。

用这个方法也可以继续推算出，一个不询问的客户，成交概率会从20%下降到15.2%。

一个销售老手的每一步都在收集信息，进行概率判断，所以有经验的销售员接下来不是干巴巴地介绍产品，而是进一步询问客户的需求，不同的需求分别对应着不同的成交概率。

好了，我们又遇到了跟前面一样的问题，就算概率从20%上升到29%，我还是不知道自己该怎么办？

四、直到有操作意义的概率

顾客在来之前就知道自己会不会买东西，假设这人今天一定要买到，实际成交概率就是100%。

但销售员并不知道这一点，他只知道，客户最终只有买（100%）和不买（0%）这两种可能。

29%只是第一步的结果，他还可以不断寻找新的信息，通过“贝叶斯算法”改变概率，以接近实际目标概率——到底是0%还是100%。

这正是贝叶斯概率相对古典概率的意义，一定要找到有操作意义的概率的信号。

于是，销售员注意到，顾客又问了另一个完全不相干的商品——不好，经验告诉他，这种情况下的成交概率会下降，因为很多不成心买的客户就喜欢东问西问。

但到底会下降多少呢？我们开始第二次“贝叶斯计算”，再引入两个条件概率，成交客户中，问过其他完全不相干商品的比例是30%，未成交客户中，有40%。

以下是第二次贝叶斯计算的图，需要说明的是，现在的先验概率不再是之前的20%，而是上一次计算后的约29%：

这个结果表明，当顾客问了另一个完全不相干的商品，他的成交概率从29%再次下降为8.7%/（8.7%+28.4%）=23%

还好，问完后，客户直接开始谈价格，很好，根据谈价格的行为的“第三次贝叶斯公式”，最终成交概率猛得上升到70%……

70%！等的就是你，销售员也就不藏着掖着了，直接拿出大杀器——折扣，顺利将客户拿下，成交概率最终定格在100%。

在这个过程中，虽然一开始你只有一个与实际结果相差很大的先验概率，但通过掌握更多的信息，这个概率会越来越接近实际情况——0或100%，到了一定数值，你就可以作出应对。

很多人肯定想问，我怎么才能知道这些条件概率呢？答案就是两个字——先试。

这些都是在以往大量的销售实践中，渐渐总结出来的，并且始终不断更新，比如今天的这个中年男人，假设在85%的成交概率下，最后竟然没有买，这个经验就会改变销售人员的那些先验概率和后面的一系列条件概率。

所谓“经验”，就是你在某个专业方向，掌握了先验概率和大量条件概率。

到了这里，我们就可以用“贝叶斯算法”回答开头的投资机会分析的问题了。

五、投资中的概率

每个人都有自己最擅长的研究方法，用此方法选出的股票，在一定时间内（比如1年）符合预期收益率的概率，可以作为一个“先验概率”。

这个概率都不会太高，比如一般不可能超过60%（除非是特别长线的方法，或者符合要求的标的特别少的方法），否则，你只需要这一个指标，选20个股，就可以年年获得超额收益了。

如果你之前用此方法的战绩不错，那就可假定为55%。

接下来可以代入条件概率：在所有能/不能达到你的预期收益的公司中，管理不好的概率分别为多少。

事实上，这两个条件概率并不会相差太大——这个条件概率差异，称之为“区分度”，因为你的考虑时间是一年，这么短的时间，管理因素几乎可以忽略不计。而且，对于离职人员评价公司“管理混乱”的概率其实是非常高的，否则，离职的原因总不能是“自己能力不高吧”？

我们假设在所有能/不能达到你的预期收益的公司中，离职人员认为管理好的概率分别为20%/25%。

第二次贝叶斯计算后的结果为53%。

由于管理因素在一年期的投资中区分度不够，概率只是微微下降，仍然在50%以上。

投资者特别容易因个人好恶，用某个因素对标的进行“一票否决”，实际上区分度并没有这么大，没有贝叶斯概率，也就谈不上理性投资。

接下来的条件，“动销好”对一年期的投资结果影响的区分度就大多了，在符合/不符合预期的标的中分别为50%和30%。

区分度越大，这个条件的影响越大，在加入“动销好”这个条件后，投资收益符合预期的概率就上升到65%。

接下来，每发现新的信息，你都可以用贝叶斯算法，更新“符合预期收益”的概率。

投资高手会设定一个买入的概率，比如70%，一旦新的条件使概率上升到70%，就可以买入，后续再根据新的信息统计分析概率，继续上升到某一个水平比如80% ，则继续加仓，如果下降到某一个概率，比如低于55%，就结束投资。

六、三类贝叶斯主义的投资高手

总结一下上面的方法：

第一、投资机会的判断=判断达到预期收益率的概率

第二、随着新信息的出现，这个概率也在不断变化

第三、随着概率的变化，也要进行相应的操作

常常有人在后台留言说，刚大，我找到一个堪比苹果之于巴菲特的公司，你看看怎么样？

非常遗憾，苹果的成功不是巴菲特一开始就算出来的，而是一年年符合预期而“剩者为王”的，一个苹果背后就有99家公司不符合巴菲特继续持有的要求，因为新信息出现导致后验概率下降。

投资是一场长跑，贝叶斯概率就是你的导航。

从贝叶斯概率的角度看，所谓高手有三种：

第一种是贝叶斯计算能力超强的高手。

最典型的是量化程序，人干不过机器的地方在于：机器用固定的算法每时每刻在全部标的中搜索符合要求的投资机会，而人是凭感觉和经验在有限的几个标的中，思考大致符合要求的投资机会，有时还考虑用什么样的投资方法。

所以真正的投资高手，可能你问他什么是“贝叶斯计算”，他一脸懵逼，那是因为他把贝叶斯计算完全内化了。

比如巴菲特曾说：“用亏损的概率乘以可能亏损的金额，再用盈利的概率乘以可能盈利的金额，最后用盈利的结果减去亏损的，这就是我们一直试图做的办法。”——这就是计算预期收益率。

第二类是擅长挖掘有区分度的信息的高手。

通过前面的例子，可以看出，大部分新信息的区分度都很有限，你觉得有用的信息，可能在那些不好的股票上也同样有用，并不足以让最终概率大幅提升。

所以最常见的高手都是在某一个大众缺乏认知的地方，掌握了一些少有人掌握的“条件概率”，比如专注于某一个行业，洞察此行业一些特殊的规律与现象，以此比别人更早发掘胜率高的投资机会。

还有“一招鲜+快速交易+果断止损”的短线高手，并不需要太高的胜率，只需要图形好（先验概率）+择时（稍高的胜率）。

更厉害的是观察市场风格变化的高手。同一类信息在不同时期，区分度也是不同的，比如2017-2020年，ROE指标的区分度就非常好，但2021年以后就失效了，而分红率指标，在2021年前没有什么区分度，但21年以后，区分度大大增加。

此类高手，擅长洞察常见的指标在不同时期区分度的变化，以及背后的宏观因素，及时加大最有效的因子，改变自己的选股风格，以适应不同的市场。

第三类高手拥有更高的“先验概率”。

大部分人在选股阶段的“先验概率”都差不多，靠的是后续找到有区分度的新信息，而第三类传说中的高手，在选股阶段就有更高的“先验概率”，之后只要用“淘汰指标”筛选掉不符合要求的标的就行了。

最典型的是一些有核心资源圈信息优势的大佬，还有那些有能力主动引导题材与市场情绪的大资金，只需要“先验概率”就能立于不败之地。

这类高手中还有一种天赋异禀、耐心超群的人，有一套极高的“先验概率信号”，但符合要求的情况极少，大部分情况下都在耐心等候，一旦信号出现，立刻加杠杆干。

七、结尾

很多人都会告诉你，投资要做大概率正确的事，比如买白马。

但这种古典概率的思想，在投资中的结果往往是“四库全输”，因为人的行为会改变概率，人人都说白马好，白马就会被抬高到毫无赔率的价格，人人避之不及的小概率事件，往往会出现赔率极高的机会。

古典概率所设想的那些先验的、稳定的、可知的大概率事件，注定不会出现，真实投资中的概率因人而异，而且常常因为顿悟而造成概率突变。

然而古典概率是如此的符合人的直觉，投资者总是出现“正在做大概率正确的事”的幻觉。

编辑/lambor

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

Sat, 08 Jul 2023 12:01:28 CST

Load 就是对计算机干活多少的度量，Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。

一、Load分析：

情况1：CPU高、Load高

通过top命令查找占用CPU最高的进程PID；
通过top -Hp PID查找占用CPU最高的线程TID;
对于java程序，使用jstack打印线程堆栈信息（可联系业务进行排查定位）；
通过 printf %x tid打印出最消耗CPU线程的十六进制；
在堆栈信息中查看该线程的堆栈信息；

情况2：CPU低、Load高

通过top命令查看CPU等待IO时间，即 %wa；
通过 iostat -d -x -m 1 10查看磁盘IO情况；(安装命令 yum install -y sysstat)
通过 sar -n DEV 1 10查看网络IO情况；
通过如下命令查找占用IO的程序；

      ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

二、CPU高、Load高情况分析

使用 vmstat查看系统纬度的 CPU 负载；
使用 top查看进程纬度的 CPU 负载；

2.1、使用 vmstat 查看系统纬度的 CPU 负载

可以通过 vmstat 从系统维度查看 CPU 资源的使用情况

格式： vmstat -n 1 -n 1表示结果一秒刷新一次

      [root@k8s-10 ~]# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1      0 2798000   2076 6375040    0    0    10    76   10   49  6  2 91  1  0
 0  0      0 2798232   2076 6375128    0    0     0   207 7965 12525  7  2 90  2  0

返回结果中的主要数据列说明：

r：表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程，所以，该数值越大，通常表示系统运行越慢。
b：表示阻塞的进程,这个不多说，进程阻塞，大家懂的。
us：用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy：系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
wa：IO 等待消耗的 CPU 时间百分比。该值较高时，说明 IO 等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
id：处于空闲状态的 CPU 时间百分比。如果该值持续为 0，同时 sy 是 us 的两倍，则通常说明系统则面临着 CPU 资源的短缺。

常见问题及解决方法：
如果r经常大于4，且id经常少于40，表示cpu的负荷很重。
如果pi，po长期不等于0，表示内存不足。
如果disk经常不等于0，且在b中的队列大于3，表示io性能不好。

2.1、使用 top 查看进程纬度的 CPU 负载

可以通过 top 从进程纬度来查看其 CPU、内存等资源的使用情况。

      [root@k8s-10 ~]# top -c
top - 19:53:49 up 2 days,  7:57,  3 users,  load average: 0.76, 0.79, 0.58
Tasks: 282 total,   2 running, 280 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.4 us,  1.4 sy,  0.0 ni, 95.0 id,  1.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12304204 total,  2800864 free,  3119064 used,  6384276 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  8164632 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29884 root      20   0 5346580 929332  14556 S   0.0  7.6   6:19.19 /opt/jdk1.8.0_144/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apach+
  875 root      20   0  729524 563424  38612 S   3.1  4.6  93:22.70 kube-apiserver --authorization-mode=Node,RBAC --service-node-port-range=80-60000 --advertise-address=10.68.7.162 --allow-privileged=true -+
 3870 nfsnobo+  20   0  910376 317248  22812 S   1.6  2.6  42:29.59 /bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/prometheus --storage.tsdb.retention=1d --web.enable-life+

默认界面上第三行会显示当前 CPU 资源的总体使用情况，下方会显示各个进程的资源占用情况。

可以直接在界面输入大小字母 P，来使监控结果按 CPU 使用率倒序排列，进而定位系统中占用 CPU 较高的进程。最后，根据系统日志和程序自身相关日志，对相应进程做进一步排查分析，以判断其占用过高 CPU 的原因。

2.2、strace命令分析

https://oa.kedacom.com/confluence/pages/viewpage.action?pageId=77136289

三、CPU低、Load高情况分析

问题描述：
Linux 系统没有业务程序运行，通过 top 观察，类似如下图所示，CPU 很空闲，但是 load average 却非常高：

处理办法：

load average 是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。
出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf查看是否存在 D 状态进程。
D 状态是指不可中断的睡眠状态。该状态的进程无法被 kill，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。

      等待I/O的进程通过处于uninterruptible sleep或D状态；通过给出这些信息我们就可以简单的查找出处在wait状态的进程
ps -eo state,pid,cmd | grep "^D"; echo "----"

- 查找占用IO的程序
ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

ChatGPT+麦肯锡方法论，快速了解一个行业

Fri, 26 May 2023 16:08:01 CST

如何快速了解一个行业

关于如何快速了解一个行业，我们可以站在巨人的肩膀上去思考这个问题，前麦肯锡合伙人、高管冯唐先生通过结合多年咨询行业经验与麦肯锡方法，总结出了三个关键步骤：

第1步是总结行业的100个关键词。

第2步是找三五个专家访谈，了解各种行业问题。

第3步是找三五本行业专业书籍，仔细阅读并找出共性。

第一步：让ChatGPT给出50个关键字

获取50个行业关键字的同时，要求ChatGPT以表格的方式呈现，这样我们就能通过一个表格了解到AI行业的中英文关键字、名词解释和相关的应用场景。

最开始我尝试用GPT4的联网模式（Browsing或Webpilot插件）来获取最新的行业数据，但是我发现无论是官方联网还是插件都无法正常生成50个关键字，每次到20几个关键字的时候就会显示“联网获取更多数据中...”，接着就卡死报错，所以最终没办法只能选择GPT4的默认模式，但由于生成的内容token数过长，所以中间需要两至三次点击继续按钮的操作。

Q1：用麦肯锡的快速了解行业方法，通过大量行业高频关键词来建立概念。现在我是一个对生成式AI行业不了解的小白，请你给我整理出50个常用关键词，制作成Markdown表格，表头是：关键词（英文）、关键词（中文）、介绍（限50字）、应用场景。

第二步：对关键词进行分类归纳

分类后的关键字有利于我们初步建立行业的知识框架，示例中我是以使用场景进行分类，大家也可以根据自己的需求进行分类梳理。有趣的是ChatGPT还会很细节地告诉你，同一个关键字可能会出现在多个分类中。

需要注意的是，在要求ChatGPT输出表格的时候，需要给一些补充说明，不然可能会出现所有关键词都在一个单元格中，这样阅读体验就会非常糟糕，并且合并单元格这些操作也是可以提要求的，我在没有尝试前也不知道ChatGPT可以这么玩。😂

Q2：将刚才给出的关键词按照不同的应用场景进行分类，分类结果制作成Markdown表格，要求一行一个关键词，应用场景合并单元格展示，表头是：应用场景、关键词（英文）、关键词（中文）

第三步：对关键词进一步分类并梳理学习优先级

在获取了关键字分类表后，我们对AI行业已经有了个大致的框架，接下来就是进一步了解如何学习这些关键字所涉及的行业知识。于是我们进一步要求ChatGPT站在一个行业小白的角度上，对刚才分类的场景进行二次分类，并给出每个关键字的学习优先级和相关书籍资料，这样我们就结合自己的需求梳理出该行业的学习路径了。

由于生成式模型有个特点就是喜欢瞎编，所以让ChatGPT给出参考文献的时候一定要加上“引用真实数据”这个说明，不然你找遍全网都估计找不到它给你的参考文献和书籍。没有特别要求的话，ChatGPT给出的文献内容默认是外文资料，这应该是跟训练的数据集有关，如果是在联网的情况下，大家也可以尝试要求输出中文文献。

Q3：将刚才分类好的AI关键词列表进行二级分类，并站在一个刚接触AI行业的初学者角度上，给出学习每个关键字的相关书籍（引用真实数据），以及学习的优先级（优先级按照高、中、低排列），最终制作成Markdown表格，表头是：应用场景、二级分类、关键词（中文）、优先级、相关书籍

第四步：了解行业宏观上下游

在了解完AI行业的关键字分类和大致的学习路径时，我们也可以让AI帮忙梳理一下行业宏观方面的内容，比如了解AI行业的产业链构成，以及上下游的组织关系是什么，这些内容只需要简单的一句话就能让ChatGPT告诉我们一个简化版本的AI产业链。

Q4：帮我梳理AI行业的产业链上下游构成以及组织关系，制作成Markdown表格，表头是：行业环节、上游、下游、组织关系

第五步：绘制行业知识框架导图

如果你觉得100个关键字在表格中显得密密麻麻，看起来非常枯燥乏味，那可以试试ChatGPT最近公开的插件能力，让输出的内容以思维导图的方式进行呈现，通过可视化的方式进一步加强对行业框架的理解。

示例中我使用的是“Show me”这个导图插件，而且由于插件生成速度较慢，为了方便我就限定了10个关键字，并且太多数据的情况下插件有可能报错无法输出。还有一点需要注意的是，如果不在提示词中强调用插件生成导图的话，可能ChatGPT会以代码的形式输出结果，所以问题描述的时候还是要带上插件名称比较好。

ChatGPT生成思维导图的同时，还会给出导图链接，可以跳转插件的网站中进行数据和样式的调整。

Q5：帮我梳理AI行业的10个关键字，并根据应用场景进行分类，用Show me制作成思维导图，导图的第一层级是AI行业，第二层级是应用场景，第三层级是关键字

nginx强制使用https访问的多种方法(http跳转到https)

Wed, 15 Mar 2023 13:12:39 CST

nginx强制使用https访问的多种方法(http跳转到https)

先说明一下HTTP跳转的状态码

301 Moved Permanently：该方式将所有的 HTTP 请求重定向到 HTTPS 上，并且该重定向是永久性的。客户端在收到 301 响应后，会自动将 HTTP 请求转为 GET 请求，同时将请求地址修改为重定向后的地址。这意味着，如果原始请求是 POST 请求，那么 301 重定向会将其转变为 GET 请求。此外，浏览器会缓存 301 响应，下一次请求时会直接跳转到 HTTPS 上。

302 Found / 303 See Other：这两种方式将所有的 HTTP 请求临时性地重定向到 HTTPS 上。302 Found 的响应会将请求方法保持不变，同时将请求地址修改为重定向后的地址。而 303 See Other 则会将所有请求方法转变为 GET 方法，并将请求地址修改为重定向后的地址。这两种方式都不会缓存响应，下一次请求时会再次发起请求。

307 Temporary Redirect：该方式将所有的 HTTP 请求临时性地重定向到 HTTPS 上，并且会保留原始的请求方法。这意味着，如果原始请求是 POST 请求，那么重定向后的请求仍然是 POST 请求。同时，请求地址也会被修改为重定向后的地址。与 302 Found 类似，307 Temporary Redirect 不会缓存响应，下一次请求时会再次发起请求。

308 Permanent Redirect：该方式将所有的 HTTP 请求重定向到 HTTPS 上，并且该重定向是永久性的。客户端在收到 308 响应后，会自动将 HTTP 请求转为与原始请求方法相同的请求方法，同时将请求地址修改为重定向后的地址。与 301 Moved Permanently 不同的是，308 Permanent Redirect 不会允许浏览器将 POST 请求重定向到新地址。308 响应也会被缓存，下一次请求时会直接跳转到 HTTPS 上。

497 normal request was sent to HTTPS：（HTTP到HTTPS（Nginx））Nginx内置的代码，被用于原始的HTTP的请求发送给HTTPS端口去分辨4XX在日志中和一个错误页面的重定向

推荐使用return 307 跳转码,百度、亚马逊等也是使用307跳转。

方式一:
返回 301 错误，并跳转到 https 地址

  
server{
        listen 80;
        listen 443 ssl;
        server_name  blog.c1gstudio.com;
        set $sslflag 0;
        if ($ssl_protocol = '') {
            set $sslflag "${sslflag}1";
        }
        if ($sslflag = "01") {
            return 301 https://$server_name$request_uri;
        }
}

方式二：
当 nginx 配置的站点只允许 https 访问时，我们却使用 http 去访问，此时 nginx 会报出 497 错误码。
我们就可以利用 error_page 命令将 497 状态码的链接重定向到 https

  
server{
        listen 80;
        listen 443 ssl;
        server_name  blog.c1gstudio.com;
        error_page 497 https://$server_name$request_uri;
}

方式三：
使用参数标记，只跳转一次https。
将 http 请求重写到 https 地址,并带上?https=Y参数.
PURGE方式不进行跳转

  
server{
        listen 80;
        listen 443 ssl;
        server_name  blog.c1gstudio.com;
        set $sslflag 0;
        if ($server_port = 80) {
            set $sslflag "${sslflag}1";
        }
        if ( $request_method = "PURGE") {
            set $sslflag "${sslflag}2";
        }
        if ($arg_sslsign ) {
            set $sslflag "${sslflag}4";
        }
        set $ssljumpparam "?https=Y";
        if ($is_args = '?'){
            set $ssljumpparam "&https=Y";
        }
        if ($sslflag = "01") {
            rewrite ^(.*)$ https://$host$uri$is_args$query_string$ssljumpparam? redirect;
        }  
}

方式四：
当post数据到http协议时，重定向后会出现请求方法变为 get，post数据丢失。
解决这个问题就要换返回的状态码,307是临时，308是永久.

  
server{
        listen 80;
        listen 443 ssl;
        server_name  blog.c1gstudio.com;
        set $sslflag 0;
        if ($scheme = http) {
            set $sslflag "${sslflag}1";
        }
        if ($request_method = POST) {
            set $sslflag "${sslflag}2";
        }

        if ($sslflag = "012") {
        return 307 https://$host$request_uri;
        }  
        if ($sslflag = "01") {
        return 301 https://$host$request_uri;
        }
}

方式五:
所有http 的GET请求301跳转至https,
POST等请求的用proxy_pass来接收并反代https

  
server{
        listen 80;
        server_name  blog.c1gstudio.com;

        set $sslflag 0;
        if ($ssl_protocol = '') {
          set $sslflag "${sslflag}1";
        }
        if ( $request_method = "GET") {
            set $sslflag "${sslflag}2";
        }
        if ($sslflag = "012") {
          return 301 https://$server_name$request_uri;
        }

        location / {
            proxy_set_header Host  $host;
            proxy_set_header X-Pass my_proxy;
            proxy_pass https://127.0.0.1;
        }

}

解决nginx access日志中400 bad request 错误 ( 2010-12-15)
cacti 监控 nginx status 支持ip及用户验证 ( 2010-08-04)
nginx反向代理多个域名(虚似主机) ( 2010-01-28)

The post nginx强制使用https访问的多种方法(http跳转到https) first appeared on C1G军火库.

Meta开源的ChatGPT平替到底好不好用？测试结果、加料改装方法已出炉，2天5.2k星

Sun, 05 Mar 2023 13:17:00 CST

ChatGPT 的持续爆火，早已让各大科技公司坐不住了。

就在刚刚过去的一周，Meta「开源」了一个新的大模型系列 ——LLaMA（Large Language Model Meta AI），参数量从 70 亿到 650 亿不等。因为 LLaMA 比之前发布的很多大模型参数更少，但性能更好，所以一经发布让很多研究者兴奋不已。

例如，130 亿参数的 LLaMA 模型「在大多数基准上」可以胜过参数量达 1750 亿的 GPT-3，而且可以在单块 V100 GPU 上运行；而最大的 650 亿参数的 LLaMA 模型可以媲美谷歌的 Chinchilla-70B 和 PaLM-540B。

参数量的减少对于普通研究者和商业机构来说都是好事，但 LLaMA 真的像论文中说得那样表现那么好吗？和当前的 ChatGPT 相比，LLaMA 是否可以勉强一战？为了解答这些疑问，有些研究者已经对这一模型进行了测试。

还有公司已经在尝试补齐 LLaMA 短板，想看能不能通过添加 RLHF 等训练方法让 LLaMA 表现更好。

LLaMA 初步评测

这份评测结果来自一位名叫 @Enryu 的 Medium 作者。它比较了 LLaMA 和 ChatGPT 在解释笑话、零样本分类和代码生成三个颇具挑战性的任务中的效果。相关博客文章为《Mini-post: first look at LLaMA》。

作者在 RTX 3090/RTX 4090 上运行 LLaMA 7B/13B 版本，在单个 A100 上运行 33B 版本。

需要注意的是，与 ChatGPT 不同，其他模型并不是基于指令微调，因此 prompt 的结构有所不同。

解释笑话

这是谷歌原始 PaLM 论文中展示的一个用例：给出一个笑话，让模型来解释它为什么好笑。该任务需要将世界知识和一些基本逻辑相结合。PaLM 之前的所有模型都无法做到这一点。作者从 PaLM 论文中提取了一些示例，比较了 LLaMA-7B、LLaMA-13B、LLaMA-33B 与 ChatGPT 的表现。

可以看到，结果很糟糕。这些模型 get 到了一些笑点，但无法真正理解，它们只是随机生成一些相关的文本流。ChatGPT 虽与 LLaMA-33B 一样表现很差（其他几个模型更差），但它遵循了不一样的策略：生成了一大堆文本，希望自己的回答至少有一部分是正确的（但大部分显然不是），是不是很像大家考试时应对问答题的策略？

不过，ChatGPT 起码 get 到了关于 Schmidthuber 的笑话。但总的来说，这些模型在零样本笑话解释任务上的效果与 PaLM 相差甚远（除非 PaLM 的示例是精心挑选）。

零样本分类

作者考虑的第二项任务更具挑战性 —— 标题党（clickbait）分类。由于连人类也无法就什么是标题党达成一致，作者在 prompt 中为这些模型提供了一些示例（因此实际上是小样本而非零样本）。如下为 LLaMa 的 prompt：

下图为 LLaMA-7B、LLaMA-13B、LLaMA-33B 与 ChatGPT 的更多示例结果。

很明显，赢家为 LLaMA-33B，它是唯一一个能够遵循所有请求格式（yes/no）的模型，并且预测合理。ChatGPT 也还可以，但有些预测不太合理，格式也有错误。较小的模型（7B/13B）不适用于该任务。

代码生成

虽然 LLM 擅长人文学科，但在 STEM 学科上表现糟糕。LLaMA 虽然有基准测试结果，但作者在代码生成领域尝试了一些特别的东西，即将人类语言零样本地转换为 SQL 查询。这并不是很实用，在现实生活中直接编写查询会更有效率。这里只作为代码生成任务的一个示例。

在 prompt 中，作者提供表模式（table schema）以及想要实现的目标，要求模型给出 SQL 查询。

从测试结果来看，LLaMA 在一些任务上表现还不错，但在另一些任务上和 ChatGPT 还有一些差距。如果能像 ChatGPT 一样加入一些「训练秘籍」，效果会不会大幅提升？

加入 RLHF，初创公司 Nebuly AI 开源 ChatLLaMA 训练方法

虽然 LLaMA 发布之初就得到众多研究者的青睐，但是少了 RLHF 的加持，从上述评测结果来看，还是差点意思。

在 LLaMA 发布三天后，初创公司 Nebuly AI 开源了 RLHF 版 LLaMA（ChatLLaMA）的训练方法。它的训练过程类似 ChatGPT，该项目允许基于预训练的 LLaMA 模型构建 ChatGPT 形式的服务。项目上线刚刚 2 天，狂揽 5.2K 星。

项目地址：https://github.com/nebuly-ai/nebullvm/tree/main/apps/accelerate/chatllama

ChatLLaMA 训练过程算法实现主打比 ChatGPT 训练更快、更便宜，我们可以从以下四点得到验证：

ChatLLaMA 是一个完整的开源实现，允许用户基于预训练的 LLaMA 模型构建 ChatGPT 风格的服务；
与 ChatGPT 相比，LLaMA 架构更小，但训练过程和单 GPU 推理速度更快，成本更低；
ChatLLaMA 内置了对 DeepSpeed ZERO 的支持，以加速微调过程；
该库还支持所有的 LLaMA 模型架构（7B、13B、33B、65B），因此用户可以根据训练时间和推理性能偏好对模型进行微调。

图源：https://openai.com/blog/chatgpt

更是有研究者表示，ChatLLaMA 比 ChatGPT 训练速度最高快 15 倍。

不过有人对这一说法提出质疑，认为该项目没有给出准确的衡量标准。

项目刚刚上线 2 天，还处于早期阶段，用户可以通过以下添加项进一步扩展：

带有微调权重的 Checkpoint；
用于快速推理的优化技术；
支持将模型打包到有效的部署框架中。

Nebuly AI 希望更多人加入进来，创造更高效和开放的 ChatGPT 类助手。

该如何使用呢？首先是使用 pip 安装软件包：

然后是克隆 LLaMA 模型：

一切准备就绪后，就可以运行了，项目中介绍了 ChatLLaMA 7B 的训练示例，感兴趣的小伙伴可以查看原项目。

参考链接：

https://www.linkedin.com/posts/activity-7035964259431763970-YdMK/

https://medium.com/@enryu9000/mini-post-first-look-at-llama-4403517d41a1

2022 全球网络黑产常用攻击方法 Top 10

Tue, 03 Jan 2023 00:00:00 CST

近几年，借助互联网产业发展的东风，网络黑产也迎来更加巅峰的状态，不论是从攻击效率，组织规模，亦或是收益变现能力，都在一天天变的成熟完善。根据艾瑞咨询 2020 年发布的《现代网络诈骗分析报告》，全国黑产从业者已经超过 40 万人，依托其从事网络诈骗的人数至少有 160 万人，“年产值”在 1000 亿元以上。
毫不夸张的讲，网络黑产从早期的小打小闹，发展成如今的多行业、多场景、多任务的全社会广泛渗透。在巨额经济利益的驱动下，黑灰产从业者游走在法律监管的边缘地带，利用各种网络犯罪技术与工具，逐渐形成一条分工明确、合作紧密的黑灰产业链条，并且以一种难以遏制的速度，成长起来。
简单来说，当下网络黑产产业链可分为上中下三个层级：上游黑产主要提供“武器弹药”，收集各种信息资源，并为中游提供工具和平台；中游黑产则是针对网络系统和计算机进行直接破坏、入侵，以各种各样的方式实施资源窃取的行为；下游则相当于是“销赃”，可将黑产转化为现金收益，例如利用中上游提供的信息实施诈骗、洗钱等。

网络黑产的快速膨胀以及对全社会的巨大危害，让全球警方深恶痛绝，各国开始制定各种政策、法规，持续打击网络黑产产业的发展。但是，它就像是融入了互联网的血液之中，在多重打击之下反而愈演愈烈，有的国家甚至已经成为网络黑产的温床。
同时，网络黑产的手段也越来越高明，有的是利用各种黑客技术，而有的则是深谙人性的阴暗面，以各种手法诱惑他人上当受骗，DDoS 攻击、网络赌博、网络招嫖、制作木马程序、内网渗透攻击等攻击手法。
本文列举当下最流行的网络黑产常用攻击方法，总结了 2022 全球网络黑产常用攻击方法 Top 10，带你更深刻认识网络黑产。

深度伪造

深度伪造技术是一种基于人工智能的音频、视频和图像合成技术，通过将图片、音频或视频合并叠加到源图片、音频或视频上，借助神经网络技术进行样本学习，将个人声音、面部表情及身体动作拼接合成虚假内容。

深度伪造最常见的方式主要包括 AI 换脸技术，语音模拟、人脸合成、视频生成等，技术人员通过样本学习，逼真模仿出原人物的面部表情、肢体语言。深度伪造技术民用化最早追溯到 2017 年，当时美国一个网友发布一款名为“深度伪造”的软件，两年后，我国出现了一款“ZAO”换脸社交软件，一时风靡。
深度伪造技术不断演进，几乎可以达到以假乱真的地步，民众仅通过肉眼无法辨别真伪，使得篡改或生成高度逼真且难以甄别的音视频内容成为可能，带来一系列安全问题，部分不法分子利用该技术恶意拼接色情视频，进行勒索活动，产生极其恶劣的社会影响。
或许，人脸、声音、视频替换将成为网络黑产下一个阶段的重点发展方向，黑客将使用这项技术进行恐吓诈骗，网络欺诈。不仅如此，生产变脸和变声工具、提供虚假语音和视频合成服务也会成为网络黑色产业链中一个新的环节。

探针盒子

2019 年央视 3·15 晚会期间，“探针盒子”第一次走进民众视线，当天记者曝光一种 WiFi 探针盒子，当用户手机处于 wifi 打开情况时，探针盒子发现信号后，会识别出手机的 MAC 地址，然后在根据 MAC 地址转换成 IMEI，之后再转换成用户手机号码。

直白讲，探针盒子就是一种 Wi-Fi 路由器，当用户手机连接“探针盒子”发出的 Wi-Fi 网络信号时，探针盒子会自动获得手机 MAC 地址，随后便将其上传至非法云端数据库进行匹配，在自动进行 MAC 地址、IMEI 串号、手机号之间的匹配关联，返回一系列的数据，其中有机主的号码、应用软件的下载和使用情况和相关浏览数据等。
日常生活中，许多商场、酒店、餐厅、咖啡厅、健身设施等场地都会突然弹出免费 WiFi 蹭网提示，这些如果是非法分子布置的探针盒子，一旦用户连接，便会悄无声息盗取手机号码，后续可以用于“精准营销”。
目前，网上仍有许多售卖 WiFi 探针盒子设备的网店，并表示帮助对接到代理商平台，导出探针盒子附近采集到的手机数字信息。我国法律规定，利用探针盒子获取他人手机号等隐私信息的行为，涉嫌侵犯他人隐私，严重情况下可能面临民事侵权责任及治安管理处罚责任。

窃取指纹面容声音等生物信息的方式

目前，生物识别信息已应用到社会各环节，生物识别信息技术利用开始逐渐平民化，极大提升了用户使用体验，但网络犯罪分子也开始盯上了这块“香饽饽”。

相较于其它民众个人信息，生物识别信息是物联网时代背景下，将民众指纹、人脸、声音、基因、虹膜等个人特征，进行数字化处理后的信息，具有不可替代性。因此，生物特征信息无可争议属于民众个人信息中最敏感的部分。
但近几年民众生物识别信息屡遭侵害，网络犯罪份子通过 AI 合成技术伪造人脸、声音、指纹，或者在未告知情况下，偷拍、收集民众人脸信息、指纹，进行非法行为，侵犯民众个人生命财产安全。
目前，生物识别信息技术广泛应用于支付、日常通行、通信等几个方面，违法收集、盗取转移、贩卖民众生物识别信息构成了上下游产业链。生物识别信息如此重要，相关机构势必要对实行人脸识别、录入的单位及相关人员严格限制，应当对拥有类似虹膜、指纹、刷脸等一些生物特征识别技术的企业进行规范监管。
政府部门已经在加快推进个人信息保护立法，近些年，网信办、工信部、信息安全标准化技术委员会等部门接连发布文件，对生物识别信息实行规范性管理。

撞库攻击

此前，网络犯罪分子获取受害者账号信息主要通过感染系统后，横向移动破解，效率低、步骤繁琐，而且仅能获得单一账号详细信息，“撞库” 出现很好解决了这些问题，成为黑客盗号的重要手段。

对于普通民众而言，“撞库”无疑是一个专业名词。通俗讲，撞库是网络犯罪分子通过收集互联网已泄露的用户信息，生成对应字典表，尝试批量登陆其它网站后，便可以得获取一系列用户账号信息。许多用户在不同网站设置相同账号密码，可以利用获取的字典表随机登录任意网站，这个过程就可以简单理解为撞库攻击。

常见的撞库场景主要有以下两种：

弱密码嗅探：类似 111111、123456 这样的简单密码因为很多人用，用这样的弱口令去试探大量的账号，就有一定概率能发现一些真正在使用弱密码的账号。
利用拖库数据：这是攻击成功率更高的一种方式，原理是大多数人倾向于在多个站点上使用同一个密码。当攻击者成功入侵一个安全防护能力很弱的站点 A，并拿到其数据库的所有用户名密码组合，然后再拿着这些组合去站点 B 尝试，如果你两个站点都注册过并且使用了同样的密码……撞库就成功了。

钓鱼网站

钓鱼网站一般指诱骗用户填写信息的虚假网站，毋庸置疑是安全人最熟悉的黑产模式。钓鱼网站何以坚挺十几年？离不开其诈骗网页与真实网站界面别无二致，很难区分，一旦潜在受害者进入界面，所提交的账号和密码等敏感信息便会立刻被黑客抓取。

钓鱼网站作为网络黑产“钉子户”，虽难以彻底拔除，但也早已被安全人员研究透彻。通常情况下，网络犯罪分子会分发伪装成受害者企业内部邮箱或者某些权威性网站。这些邮箱或网站地址具有极高相似度，最大的区别在于其有且仅有几个页面，甚至只有一个页面。
常见钓鱼方式主要包括“鱼叉攻击”、“商业邮件欺诈”、“灯笼式钓鱼”、“克隆钓鱼”、“域名欺骗”、“短信钓鱼”、“语音钓鱼”、“域欺骗”、“水坑攻击”等方式，攻击者利用上述方式进行非法信息收集，潜在受害者往往会泄露个人信息，如姓名、电话、家庭住址、身份 ID，甚至信用卡号、账户用户名和密码等内容也会被攻击者获取。
钓鱼网站最早案例可能要追溯到美国，几十年前，美国互联网产业发展迎来高峰期，无数网络犯罪分子企图通过钓鱼网站，攫取经济利益。随着全球互联网产业融合发展，亚非拉等区域计算机产业井喷，钓鱼网站攻击开始蔓延全球。钓鱼网站难以彻底拔除，根源在于即使大多数民众很清楚钓鱼网站的套路，但还是难以抵挡各种诱惑。钓鱼网站运营者熟练运用社会从工程学，抓住人类贪婪、恐惧、羡慕、虚荣、善良等各种情绪，付出极小代价便可获得受害者“秘密信息”。

色情网站

互联网江湖五花八门，黑客组织各显神通，色情网站自然占据一席之地，迫于法律法规，当下多采用地下模式存活。当用户偷偷摸摸访问这些网站时，自以为无人知悉、天衣无缝，殊不知获取视频数据过程中，网站内部嵌入程序已经在偷偷抓取用户手机信息，悄无声息窃取手机号码，浏览器记录、IP 地址，甚至相册、通讯录等机密信息也难逃一劫。

不止如此，某些色情 APP 还会雇佣黑客组织，利用境外服务器群发附有病毒的链接，一旦点击，木马病毒便会植入手机，横向获取银行卡信息、真实姓名、通讯录等敏感信息。更可怕的是，黑客还通过用户通讯录，群发所有好友。
部分色情网站窃取信息是征求用户同意后的行为。当用户打开一个视频，准备“欣赏”，突然弹出一个界面，需要获得存储权、相机、通讯录权限，一旦点击同意，无疑同意网站收集用户个人信息。不单技术手段，部分色情 APP 暗地里直接兜售用户个人数据，明码标价，“童叟无欺”。
色情网站的危害远不止于此，如何终止色情网站运行，阻断色情内容扩散，是社会以及各大网络搜索平台亟需解决的问题。

收买内鬼

直接攻击获取信息的手段已经不能满足网络犯罪分子的野心了，目前，这群人也开始玩起无间道，培养内鬼。何为安全行业内鬼？潜伏在企业内部，为攻击者提供登陆凭证、漏洞情报，企业消息，资源详情的”特务人员“就是内鬼！

有道是日防夜防家贼难防，网络犯罪分子”火力全开“使用各种攻击手段，投入大量资源，不见得能够洞穿企业安全防护体系，但只需要很小的一部分资金便可以收买内鬼，轻松突破防线，盗取、锁定企业数据。
网络空间中，不仅有急需内鬼的买方，卖方同样无时无刻不在兜售自己。微信群聊中，部分人员打着“公司内部信息”旗号，倒卖数据的事件在日常正并不罕见，“内鬼监守自盗，成为民众、企业数据信息流向暗网交易市场的重要渠道之一。
在 2020 年，公安机关办理的数据安全案件中，涉及到内鬼利用工作之便窃取、泄露公民个人信息的违法犯罪行为，查获重点行业内部涉案人员 500 余名。目前，圈内最火的黑客组织 LAPSUS$ 也是收买企业内鬼的”忠实拥趸“，为轻松突破目标企业安全防御体系， LAPSUS$ 提出一种创新型方法，针对目标企业，在论坛或者社交软件 Telegram 上，用各种语言广发“英雄贴”，蓄意丰厚报酬，试图招募目标企业员工献出其内部登录凭证。
”内鬼“之所以如此具有价值，归咎于企业机构中，对数据信息权限的管理不够明确，许多企业存在内部数据无分级，任何人都能查看、下载等情况。在高额金钱诱惑下，难免有小部分人员动歪心思。

伪基站

伪基站顾名思义就是伪冒基站，是一种利用 GSM 单向认证漏洞的非法无线电通信设备，主要由主机和笔记本电脑组成，能够搜取以其为中心、一定半径范围内的 GSM 移动电话信息，并任意冒用他人手机号码强行向用户手机发送诈骗、推销等垃圾短信，常部署在汽车或者一个比较隐蔽区域。（伪基站产业猖狂时期，能够在街上看到某些车辆鬼鬼祟祟，围绕某片区域巡逻）。

伪基站原理相对简单，当运营时覆盖范围内的用户信号被强制连接到该设备上，无法连接到三大运营商的网络信号，以影响手机用户正常使用，之后利用移动信令监测系统监测移动通讯过程中的各种信令过程，获得手机用户当前的位置信息。
伪基站启动后会立刻工作，开始屏蔽一定范围内的信号，趁着用户信号短暂中断，搜索出附近连接伪基站的手机号，随机将短信发送到这些号码上。一般而言，伪基站的作用时间持续10 秒到 20 秒，恰好允许短信推送。
伪基站具有隐蔽性、持久性等特点，加上往往部署在灵活性较高的汽车上，因此伪基站还具有较强流动性。目前，伪基站仍然可以通过特殊渠道购买，国家已经出台相应法规，例如《中华人民共和国刑法》第 288 条和《中华人民共和国治安处罚法》第 28 条都分别规定，擅自使用无线电台，经无线电管理部门责令停止使用后拒不停止使用的，或故意干扰无线电业务经有关部门指出后拒不采取有效措施消除的，移送司法部门处罚。

DDoS攻击

DDoS 攻击，官方定义为多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了多个位于不同位置的机器并利用这些机器对受害者同步实施攻击。直白点，就是攻击者利用已被攻陷的电脑，在较短时间内对目标网站发起大量请求，大规模消耗目标网站的主机资源，集中火力”围殴“受害者，使其无法正常服务。

DDoS 攻击表现形式主要有两种，一种为流量攻击，主要是针对网络带宽的攻击，即大量攻击包导致网络带宽被阻塞，合法网络包被虚假的攻击包淹没而无法到达主机。另一种为资源耗尽攻击，主要是针对服务器主机的攻击，即通过大量攻击包导致主机的内存被耗尽或 CPU 被内核及应用程序占完而造成无法提供网络服务。
当被企业系统被 DDoS 攻击时，主要表现出以下几种情况：

1. 被攻击主机上有大量等待的 TCP 连接。2. 网络中充斥着大量的无用的数据包，源地址为假。3. 制造高流量无用数据，造成网络拥塞，使受害主机无法正常和外界通讯。4. 利用受害主机提供的服务或传输协议上的缺陷，反复高速地发出特定的服务请求，使受害主机无法及时处理所有正常请求。5. 严重时会造成系统死机

针对企业的 DDoS 频频发生，从《2022 上半年全球 DDoS 威胁报告》数据显示，随着企业数字化、云化，DDoS 攻击次数已连续数年高速增长，已达去年同期的 3 倍，并且攻击手段、攻击烈度也在不断进化。
值得一提的是，网络犯罪分子为增加非法收入，会在暗网上出售 DDoS 服务，无差别攻击企业机构，获取佣金、赎金双倍利益。更有甚者部分勒索团伙毫无职业精神，即使受害者选择支付赎金，也不会解绑系统，甚至会“转卖受害者”，进行双重勒索。

假冒 APP

随着移动互联网技术快速发展，APP 已成为民众获取获取信息、娱乐交流、消费投资等各类生活需求的主要媒介。APP 大量使用便利民众同时，假冒 APP 也随之出现，成为一些网络犯罪分子攫取利益的工具。

区分正规 APP 和假冒 APP 的关键点在于用户支付时资金流向问题。正规 APP 充值方式都是集成在平台上，在 APP 上可以直接用绑定的银行卡进行充值，假冒 APP 的充值方式通常是诱导受害者通过银行卡或者支付宝、微信直接转账到对方账户。
从以往暴雷的事件来看，假冒 APP 并不是简单页面相仿、操作流程相似，而是经过团伙内开发人员、运维、产品等相互协作，严格分工，流程化设计，精准仿冒，量身定制假冒 APP 中各种诈骗流程，最后经下游渠道封装和分发假冒 APP。
各环节疏通后，假冒 APP 最终流向诈骗团伙，随后诈骗团伙根据假冒 APP 的功能特点，将其包装成极具迷惑性的“正规”应用平台，诱使潜在受害人点击链接或扫描二维码下载 APP，进而实施诈骗活动。

网络黑产发展趋势

网络黑产凭借其隐匿性、复杂性、灵活性，暗地里利用 DDos 攻击、钓鱼网站、色情网站等技术手段，谋取大量的经济利益。此外，为躲避法律监管，利益最大化，国内网络黑产组织彼此之间相互配合，形成上下游一体化“作案”，上游专门负责利用系统漏洞，盗取受害者数据信息，下游组织掌握庞大交易平台，分类数据，更为精准定位目标客户，最终实现利益最大化，俨然是一派分工明确、组织严密的“和谐景象”。

现阶段，网络黑产逐渐升级技术手段、转移运营区域、加强不同组织间协作、优化宣传方式、谋求合法身份，呈现出智能化、国际化、平台化、涉众化、产业化的发展趋势。更值得警惕的是，网络黑产早已盯上了年轻群体，青少年群体心智尚未成熟，法律意识薄弱，缺乏是非判断力，极易容易成为黑产引诱的对象。
网络黑产治理，任重道远！

精彩推荐

高可用架构的设计方法

Wed, 09 Nov 2022 18:27:03 CST

我们来自字节跳动飞书商业应用研发部(Lark Business Applications)，目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统，也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎各位加入我们。

本文作者：LBA 许家强

概述

高可用(High Availability)，简称HA，是衡量IT系统服务质量的一个极其重要的参考，高可用一直是IT系统设计中需要重点关注的点。本文总结高可用架构中的一些关键设计思想。

衡量指标SLA
SLA是衡量网站服务可用性的一个关键指标，现在互联网公司一般以X个9来表示在系统1年时间的使用过程中，系统可正常使用时间与总时间（1年）之比，9越多代表全年服务可用时间越长、服务更可靠、停机时间越短，反之亦然。

一般而言，如果系统达到4个9就非常优秀了，需要在设计上做足功夫。

冗余

冗余是构建高可用的重要手段。其核心思想是对分布式系统中的节点进行备份。备份会分为冷备和热备。

冷备，一般会有主数据中心和备数据中心，正常情况下是主数据中心提供业务服务，备份中心不会有提供业务服务，而是会定期从主数据中心进行备份（非实时备份），也就是说如果主数据中心出现故障，业务也就中断了，需要人工进行干预，将流量从主数据中心切换到备数据中心。
热备，主要是对主数据中心进行实时性的备份，以保证在主数据中心出现故障后可以及时的切换，让用户不受影响的继续使用。关于主数据中心到备数据中心的复制方式，分为同步和异步两种分式。
- 同步方式，当主节点处理完请求后，会同步向多个备节点实时备份数据，只有所有节点数据同步完成，主节点才会向客户端返回成功。这种方式对可用性有较大损耗，一般不推荐使用，
- 异步方式，当主节点处理请求后，会向客户端返回成功，同时会异步触发向多个备节点实时备份数据。该情况下，主备节点的数据会存在数据不一致或者延时，业务上需要能容忍一定程度的数据延迟。互联网系统一般会采用这种方式。

从备节点的工作方式划分，又可以分为双机互备和双机热备。

双机热备，从狭义上讲是使用互为备份的两台服务器共同执行同一服务，在正常情况下，工作机为应用系统提供服务，备份机监视工作机的运行情况，出故障时备机可迅速接管服务。
双机互备，是指主机和备机互为备份，备机上运行与主机不同的应用，例如两台server安装相同的系统、应用软件，主机备机同时工作，主机跑ORACLE，备机跑IIS，任意一台服务器故障时，所有服务会自动切换到正常的服务器上。

集群

集群是相对单机而言的，集群部署是分布式系统的典型特征。集群的作用其实就是分流，这里面不得不提核心的分流技术。

负载均衡

分为硬件负载和软件负载。

硬件负载：通过硬件来进行分流，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，一般在互联网系统较少使用，主要用于金融行业的核心服务；
软件负载：通过软件实现分流，如Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，费用非常低廉。

按所处OSI模型的工作层级，可分为7层负载和4层负载。

7层负载，是指工作在网络7层，基于URL等应用层信息的负载均衡，主要代表有Nginx。
4层负载，就是基于IP+端口的负载均衡，主要代表有LVS。

DNS

Domain Name System，“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它所提供的服务是用来将主机名和域名转换为IP地址的工作。一般大型网站的域名，背后会绑定多个vipServer的地址，DNS可以通过智能域名解析系统，返回离用户最近的vipServer 的ip。

容错

容错能力也是影响IT系统可用性的一个关键要素。

狭义的容错，一般会在设计上体现在以下方面:

对用户的输入进行尽早的校验，不信任外部的输入。
程序中尽可能的考虑边界及异常的情况。

广义的容错应该是两个具有明确边界的事物（如服务间，系统间）交互时候针对可能发生的一切主客观异常情况的防御性手段。常见的容错机制有failsafe、failback、failover、failfast。

failfast

快速失败，尽可能的发现系统中的错误，使系统能够按照事先设定好的错误的流程执行，避免资源耗尽或积压导致系统滚雪球式崩溃。我们通常讲的熔断就是这个思想。

failover

失效转移，它和前面提到的冗余备份关联很紧密。当主要组件异常时，其功能迅速转移到备份组件。MYSQL的双主模式、Zookeeper的自动选举、Redis的哨兵模式，都是基于这种思想，目的是尽量减少部分节点故障对用户服务的影响

failback

自动恢复，是相对failover而言的，簇网络系统（有两台或多台服务器互联的网络）中，由于要某台服务器故障进行维修，需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程，称为自动恢复。一般依赖心跳探测技术来实现自动恢复，例如dubbo服务中的应用实例出现down机后，在服务恢复后会自动注册到config server，重新对外提供服务。

failsafe

失效安全，即在故障的情况下也不会造成伤害或者尽量减少伤害。并非所有的故障对用户都是致命的，当这类非关键的故障出现时可以忽略，因为这种故障不会造成损失或损失在可接受范围内。

多活

双活/多活架构，关键点是指不同地理位置上的系统都能够提供服务。“活”是指实时提供服务，与“活”对应的是字是“备”——备是备份，正常情况下对外是不提供服务或只提供部分服务（例如DB读写分离），如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让“备”变成“活。

实现多活有较高的成本，要考虑数据一致性、网络延时问题。

常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样。

同城双活

是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制，保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。

该架构优点是方案简单、成本较低、网络延时小，缺点是由于双机房都在同城，所在城市出现网络故障或自然灾害时，服务可用性无法保障。

两地三中心

指同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。

该架构的优点是相比同城双活，增加了异地灾备能力；缺点是异地的备份数据中心是冷的，出故障时异地机房是否能顺利接管流量是个大问题。

异地多活

异地的一个核心问题是物理距离带来的延时，因此要避免一次请求在异地的多个机房之间流转，因此异地多活的核心是单元化，要保证单次请求在一个固定机房内封闭。

单元化，在技术上的核心挑战在于流量路由和数据同步。这里还需注意，有些应用和数据是没法单元化的，因此还会衍生出中心机房和单元机房的概念，对于没法单元化的数据必须在中心机房。阿里的淘宝是国内最早完整成功实施单元化的系统，其在全球化部署上也有较多成功的实践，在此就不展开了。

去中心化

在一个分布有众多节点的系统中，每个节点都具有高度自治的特征。节点之间彼此可以自由连接，形成新的连接单元。任何一个节点都可能成为阶段性的中心，但不具备强制性的中心控制功能。节点与节点之间的影响，会通过网络而形成非线性因果关系。去中心化架构的特征：

去中心化，不是不要中心，而是由节点来自由选择中心、自由决定中心。
任何中心都不是永久的，而是阶段性的
任何中心对节点都不具有强制性

常见的中心化设计：

ESB
单体系统
网关

常见的去中心化设计：

DUBBO、MESH等
用SDK替代服务

加入我们

扫码发现职位&投递简历

官网投递： job.toutiao.com/s/FyL7DRg

欢迎大家关注 飞书技术，每周定期更新飞书技术团队技术干货内容，想看什么内容，欢迎大家评论区留言~

自律很难？其实是你用错了方法。

Sun, 30 Oct 2022 16:50:25 CST

这个时代任务很多，焦虑也很多，作为打工人或学生，完成任务，获得资源是每天都需要疲于应对的事情。

在这种状态下，自律成为了人们追求高效和成功的一把钥匙，但是大家都在喊口号、立flag，但是一旦工作学习起来，自律就变得非常难。

有很多人在做不成某些事情之后，就只是把自己贴上“懒”“心态不好”等负面的标签，这种思考的深度注定无法帮助你走出不自律，因为你只是蜻蜓点水式的给自己贴上了一个无用的标签，并没有进行接下来的深度思考，所以自律也不会有所改变。

其实自律能够达到，有两大方向上的因素。

第一大方向，是你的身体资源和心理资源是否能够支撑你完成你要完成的目标和任务。

就拿一件每个人每天都要面对的事情来举例---起床。

起床这件事看似简单，其实难倒了很多人，有些人很容易早起，并且精神饱满，很快就能投入工作和学习中，但是有些人早上再怎么鞭策自己，就是很难起来，如果靠意志力去支撑自己，过不久就会出现身体问题。

我有一位朋友，她说自己是那种晚睡晚起的类型，但是由于学习和工作的关系，逼迫自己每天晚上十点睡五点起，一个月之后，得了很严重的荨麻疹。

其实这场荨麻疹是她身体中反抗这种生活习惯。

我们要知道每个人身体的状态和生理基础都有差异，你不习惯早起或许不只是你懒那么简单，而是你的生理规律就是更适应晚睡晚起的规律，那么如果你一定要找一个早起类型的工作，你再怎么给自己打鸡血，逼迫自己自律也没有用，只会折磨自己。

心理资源也是一样，很多人在遇到工作困难的时候会想到拖延和退缩，但是他们并不知道自己具体退缩的原因为何，他们只会责怪自己不上进、懒、能力不行等等。

其实更深层的根源是你的知识、能力、以及心理素质在这个阶段很难应对眼前的这个困难，所以你才会想要避开。

特别是心理素质和能量十分重要，因为知识和能力在短时间内可以得到补充和学习，但是心理素质和能量是一个长时间形成和积累的结果，短时间改变起来比较难，所以你在这个时候，不去看到这里面深层的原因，而只是要求自己去达标、去自律是没有用的。

在心理能量不足的时候，你要学会的是如何降低心理预期，并且改变自己看待无法完成某个目标和任务的归因方式。

必要的时候，放弃一些目标也是很有必要的。

第二大方向，就是应对目标的方法出了问题。

我给大家总结了几个比较常见的目标管理误区：

01.时间规划vs时间复盘

还记不记得小时候放暑假的时候，当妈妈让你好好规划一下每天该做些什么的时候，你会非常习惯的掏出一个小本本，写一个类似于日程表的东西：

8.00起床

8.10洗漱

8.20-8.40吃早点

8.50-9.30写语文作业

9.30-10.00写数学作业

.........

这个方法看似井井有条，但等你开始操作时，你会发现自己一直被时间追着跑，但凡其中一件事情脱离了规划，整个日程就乱套了，你就很容易陷入到焦虑中。

但是一天下来，你发现这些目标实现不了自己，等到明天你就会因为昨天没有办法实现自己规划的目标而感觉到气馁和挫败，于是第二天就不想继续了。

并且，这种方法还有一个缺点，就是非常形式主义，比如，如果再九点三十之前就已经写完了语文作业，那么剩余的时间你怎么安排，你或许会浪费这部分的时间，这并没有为你提高效率，而是被日程表框住了。

正确的时间管理方法，是我们应该转换一下思路，时间管理的最终目的，是为了让我们设计一个符合我们自身学习和工作节奏的时间工作，辅助我们更高效的完成任务，并且这套方法应该是灵活的，可以调整的。

所以我们不能只是一开始死板的给自己画一个圈，把自己圈入到某个日程表中，而是先要学会观察我们自身的学习工作状态，做一小段时间学习过程的观察复盘，然后逐步调整属于自己的规划表。

这里有两个步骤：事前规划+事后记录

你只需要在做完某件的时候，去记录一下它的开始时间和结束时间。

记录的时候注意两点：

第一点，记得记录纯时间而不是毛时间。

比如你学习了一个小时，但是15分钟在玩手机，你就要把这两项时间分开记录，否则你就无法精准的记录自己学习的精力到底可以持续多久，会影响接下来任务的安排。

第二点，你需要同时记录自己在这个过程中使用时间的感受，这个很重要。

你对使用世间得饿感受决定了你是否可以持续的以这样的方式去工作和学习。

比如，你每天给自己安排半个小时背英语单词，但是你每次背到十五分钟的时候就会觉得很累，注意力无法很好的集中，这个时候你就需要去记录一下感受，因为这说明半个小时的英语单词对于你来说其实有些困难，你需要调整你的学习机会和任务。

记录时间使用的感受可以让你明白自己学习和工作的使用能力，知道自己的饱和度和极限在哪里。

当你达到饱和度和极限时，就要学会去调整和优化目标，而不是鞭策自己一定要达到目标，这是不现实的。

02.任务清单vs目标罗盘

很多人最开心的事情，就是能够在睡前亲手逐条的划去自己今天完成的任务，这样很有成就感。

比如：

拖地

洗衣服

遛狗

给自己做一顿好吃的

跟男朋友逛街

你有没有发现，这样被你划掉的目标都是一些非常简单的目标，一天下来，你会发现你只会挑选那些简单易行的任务先做，那些困难的任务全都被你剩下了。

结果那些剩下的任务会让你一直拖延，这样的方法压根解决不了你拖延不自律的问题。

这种办法会让你陷入一种看似很高效、很忙，其实是瞎忙的状态。

而且这种任务清单多半都是以天为单位去计划的，这种计划办法太过于粗略，很难让你看清你离自己的最终目标还有多远。

所以这种时候，我们需要使用更高维的管理办法： 目标罗盘

我们可以自己绘制一个目标罗盘。

绘制的第一步，知道自己目标的起点和终点。

起点就是你此时所在的位置，终点就是你需要达到的那个位置。

第二步，设计这个线路之间的线路图

这个线路图的设计过程还是那句话，不是一次性可以设计好的，千万不要像给自己布置暑假任务那样死板的去设计，还是要借助我在第一部分讲到的先规划，后记录的办法，根据自己当前的表现状态逐步去复盘和调整。

设计线路图的一个很重要的动作就是学会拆分你的目标，直到它可以变成你可以操作的动作。

只是拆解还不够，我们需要引入一些直观的指标去量化和衡量我们的拆解目标是否达成。

这种量化过后的目标会成为你达成目标的关键结果。

也就是说，你是否能够顺利的完成这个最终的目标，关键结果是非常重要的。

还有最后一步，记得给这些关键结果加上权重，加上权重意味着你对于自己目标的把控是清楚的，方便你在日后如果时间有限的情况下更加清晰的知道应该着重去做哪些事情。

这里推荐vision这个目标管理工具给到大家。

03.外部压力VS内在动力

心理学家爱德华·德西在1969年进行了一次心理实验。

他随机选出一些大学生分成两组，玩一种叫Soma的积木游戏。

这种玩具可以拼组成不同的形状，玩到复杂时非常具有挑战性。

两组学生要花半个小时左右的时间按照规程玩这种玩具。

第一组被告知，他们每按纸上的图案拼组成一个形状，就能挣一美元。按照1969年的物价，这对学生来说是一笔不小的钱。

另一组学生则没有任何奖励。

半个小时一到，主持实验的人告诉大家：“请等一下，我出去几分钟印出有关问卷，请各位填写。

但他出去后并非印制问卷，而是通过秘密观察孔看看屋里的动静。

结果发现奖励组的学生基本上开始停止拼图，而无奖励组的学生更倾向于继续拼图。

德西把这些实验结果归结到一个问题：是什么能有效地驱动人们的行为？是内在动机，还是外在控制？

德西效应认为适度的奖励有利于巩固个体的内在动机，但过多的奖励却有可能降低个体对事情本身的兴趣．降低其内在动机。

回到自律与目标这个问题上，你会发现，当你发自内心想要做某件事情时，你不用谁的督促就会自动去完成，甚至为此克服重重困难。

这是因为人都有自我实现的本能，都会本能的去完成自己心中的目标，这是所有人最为宝贵的心理资源。

内在动力的形成可以帮助我们更清楚的感知到我们想要的是什么，并且调用自己的能力去达成目标，而如果只是靠外部压力驱使自己，就无法真正的长期坚持下去。

所以帮助自己发掘自身的内驱力，也是一门很重要的功课，它决定你在你设置的目标上可以走多远。

作者：咿呀树(?伊然)

责任编辑：一只梨

Spring事务回滚的两种方法

Sat, 29 Oct 2022 14:32:11 CST

theme: Chinese-red

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第30天，点击查看活动详情

当然，Spring事务回滚的前提是你当前使用的数据库必须支持事务，比如MySQL的Innodb是支持的，但Mysaim则是不支持事务的。

方法一

使用 @Transaction 来配置自动回滚，可以配置在类上，也可以配置在方法上（作用域不同），但对final或private修饰的方法无效，且该类必须是受spring所管控的，也就是被已经被注入的类，而不是new出来的类。
- 若配置在方法上，则该方法被加上了事务
- 若配置在类上，则等于给该类的所有方法都加上了该注解。此时如果在该类下的某个方法也加了 @Transaction ，则该方法使用自己的配置，其他方法使用类上的配置。
```
    @Service
@Transactional
public class UserServiceImpl implements UserService {
    @Override
    public void save(User user) {
        //some code
        //db operation
    }
}
```

若被配置的方法或类抛出了异常，则事务会被自动回滚，除非你在该方法中手动捕获了异常，且没有抛出新的异常。

可以使用 @Transactional(rollbackFor = Exception.class) 来设定针对特定的异常进行事务回滚，如果不设置则默认会回滚 RuntimeException and Error （参考自源码内文档）。

    @Service
@Transactional(rollbackFor = Exception.class)
public class UserServiceImpl implements UserService {
    @Resource
private UserMapper userMapper;
    
    @Override
    public void save(User user) {
        userMapper.insert(user);
        throw new RuntimeException(); // 抛出异常，事务回滚，上面的insert插入失败。
    }
}

方法二

通过注入 DataSourceTransactionManager 来手动开启事务，手动回滚事务，用于抛出异常被catch后，进行手动回滚，可控程度更高，可以更灵活的使用。

先注入 DataSourceTransactionManager 事务管理对象
new 一个 DefaultTransactionDefinition def = new DefaultTransactionDefinition(); 对象
使用 TransactionStatus status = transactionManager.getTransaction(def);来开启一个事务，
使用 transactionManager.rollback(status); 来回滚这个事务
使用 transactionManager.commit(status); 来提交这个事务

  @Service
public class UserServiceImpl implements UserService {
   @Autowired
   private DataSourceTransactionManager transactionManager;

   @Override
   @Transactional
   public void save(User user) {
       DefaultTransactionDefinition def = new DefaultTransactionDefinition();
       // explicitly setting the transaction name is something that can only be done programmatically
       def.setName("SomeTxName");
       def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

       TransactionStatus status = transactionManager.getTransaction(def);
       try {
           // execute your business logic here
           //db operation
       } catch (Exception ex) {
           transactionManager.rollback(status);
           throw ex;
       }
   }
} // 此代码案例来自Alibaba Coding Guidelines

实例剖析4种数据仓库的建模方法

Wed, 26 Oct 2022 08:51:07 CST

数据仓库，这个几乎是所有大数据开发面试必问的话题。比如数据仓库的分层架构？为什么需要数据仓库建模？数据仓库建模的原则是什么？结合业务举例说明数据仓库建模的步骤，以及注意事项？什么是缓慢变化维？维度该如何选择建设，原则是什么，主键如何设计等等？

一众问题搞得小伙伴们死去活来，甚至工作好几年的小伙伴都没搞清楚过，尤其是大厂特别爱问这些问题。有些小伙伴甚至觉得这些都是形而上学，不懂这些我不一样搞了很多年开发？即使感兴趣的买了一本厚厚的数据仓库工具书也看不懂！那么实际数据仓库建模到底是什么，开发人员该掌握哪些？

数据仓库前世今生

来一起看个官方定义：数据仓库，英文名称为DataWarehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库之父 Bill Inmon 在 1991 年出版的 Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon 将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。

简单点来说，现实情况是一个企业有很多数据源，比如有的业务数据存放在Mysql,PG库,有的存放在Oracle，有的日志存放在Ftp，Nginx服务器上等，有的是外部采集的爬虫数据等等。那么对于企业来说沉淀了这么多数据，如何将这些数据放到一起进行数据融合，数据分析，给企业挖掘数据价值呢？这些不同数据源，不同数据存储格式，不同的数据更新周期，如果让你把企业这些数据融合分析，你怎么办？

首先，你是不是要把这些不同数据按照统一的格式，一定的规范存储到一起，然后在通过特定的工具做数据计算分析？那么对于企业来说，把企业各种数据源的数据放到一起存储和计算的地方就叫数据仓库（约定俗称的叫法），所以本质上数据仓库上融合各个数据源，存储加工数据的地方，早期大数据没有发展起来的时候，企业数据仓库的载体一般是Oracle，那时候主要给企业做BI报表（Business Intelligence商业智能）。

后来随着企业数字化，互联网的发展，企业收集到数据越来越多，发现原有的技术框架已经满足不了业务存储和分析的需求了。于是乎就有了现在Hadoop生态为主的数仓仓库。

数据仓库建模的目的？

为什么要进行数据仓库建模？大数据的数仓建模是通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑：

访问性能：能够快速查询所需的数据，减少数据I/O。

数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的存储成本和计算成本。

使用效率：改善用户应用体验，提高使用数据的效率。

数据质量：改善数据统计口径的不一致性，减少数据计算错误的可能性，提供高质量的、一致的数据访问平台。

常见的数据建模方法

数据仓库本质是从数据库衍生出来的，所以数据仓库的建模也是不断衍生发展的。从最早的借鉴数据库的范式建模，到逐渐提出维度建模，Data Vault模型，Anchor模型等等，越往后建模的要求越高，越需满足3NF，4NF等。但是对于数据仓库来说，目前主流还是维度建模，会夹杂着范式建模。

数据仓库建模方法论可分为：范式建模、维度建模、Data Vault模型、Anchor模型。

常见四种建模方法

1、范式建模（E-R模型）

将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述；实体：Entity，关系：Relationship，这种对数据的抽象建模通常被称为ER实体关系模型

ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式，且该建模方法需要满足3NF。Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型就行设计。

但是逐渐随着企业数据的高增长，复杂化，数仓全部使用ER模型建模显得越来越不合时宜。为什么呢，因为其按部就班的步骤，三范式等，不适合现代化复杂，多变的业务组织。

E-R模型建模的步骤（满足3NF）如下：

抽象出主体（教师，课程）
梳理主体之间的关系（一个老师可以教多门课，一门课可以被多个老师教）
梳理主体的属性（教师：教师名称，性别，学历等）
画出E-R关系图

2、维度建模

维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。

维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。维度建模是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

Ralph Kimball提出对数据仓库维度建模，并且将数据仓库中的表划分为事实表、维度表两种类型。

1）事实表

在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。

以电商行业为例：电商场景：一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值包括商品数量、金额、件数等。

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。

周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。

累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

2）维度表

维度，顾名思义，业务过程的发生或分析角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等较比比较手机性能维。维度表一般为单一主键，在ER模型中，实体为客观存在的事物，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。

比如商品，单一主键：商品ID，属性包括产地、颜色、材质、尺寸、单价等，但并非属性一定是文本，比如单价、尺寸，均为数值型描述性的，日常主要的维度抽象包括：时间维度表、地理区域维度表等。

案例：某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建模的方式设计该模型

涉及到事实表为订单表、订单明细表，维度包括商品维度、用户维度、商家维度、区域维度、时间维度。

商品维度：商品ID、商品名称、商品种类、单价、产地等。

用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等。

时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等图片。

维度分为：

① 退化维度（DegenerateDimension）

在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

② 缓慢变化维（Slowly Changing Dimensions）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。比如员工表中的部门维度，员工的所在部门有可能两年后调整一次。

3）维度建模模型的分类

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

① 星型模型

星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。

② 雪花模型

雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。

尖叫提示：所以由上可以看出：

星型模型和雪花模型主要区别就是对维度表的拆分。

对于雪花模型，维度表的涉及更加规范，一般符合3NF，有效降低数据冗余，维度表之间不会相互关联。

星型模型，一般采用降维的操作，反规范化，不符合3NF,利用冗余来避免模型过于复杂，提高易用性和分析效率，效率相对较高。

③ 星座模型

星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。

4）维度建模步骤

维度建模步骤：选择业务过程->声明粒度->确定维度->确定事实。旨在重点解决数据粒度、维度设计和事实表设计问题。

声明粒度，为业务最小活动单元或不同维度组合。以共同粒度从多个组织业务过程合并度量的事实表称为合并事实表，需要注意的是，来自多个业务过程的事实合并到合并事实表时，它们必须具有同样等级的粒度。

3、DataVault模型

Data Vault是Dan Linstedt发起创建的一种模型方法论，Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理。同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。

Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。

Data Vault模型包含三种基本结构：

中心表-Hub ：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。

链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。

卫星表- Satellite：历史的描述性数据，数据仓库中数据的真正载体。

1）中心表-Hub

2）链接表-Link

3）卫星表- Satellite

4）Data Vault模型建模流程

梳理所有主要实体
将有入边的实体定义为中心表
将没有入边切仅有一个出边的表定义为中心表
源苦衷没有入边且有两条或以上出边的表定义为连接表
将外键关系定义为链接表

尖叫提示：Hub想像成人体的骨架，那么Link就是连接骨架的韧带组织，而satelite就是骨架上的血肉。Data Vault是对ER模型更近一步的规范化，由于对数据的拆解和更偏向于基础数据组织，在处理分析类场景时相对复杂，适合数仓低层构建，目前实际应用场景较少。

4、Anchor模型

Anchor是对Data Vault模型做了更近一步的规范会处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型，模型范式达到了6NF。

由于过度规范化，使用中牵涉到太多的join操作，目前木有实际案例，仅作了解。

四种模型总结

以上为四种基本的建模方法，当前主流建模方法为：ER模型、维度模型。

1）ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。

缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

2）维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。

优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo。

3）数仓模型的选择是灵活的，不局限于某一种模型方法。

4）数仓模型的设计也是灵活的，以实际需求场景为导向。

5）模型设计要兼顾灵活性、可扩展，而对终端用户透明性。

6）模型设计要考虑技术可靠性和实现成本。

常用建模工具

建模工具，一般企业以Erwin、powerdesigner、visio，甚至Excel等为主。也有些企业自行研发工具，或使用阿里等成熟套装组件产品。

作者丨涤生

Linux主机性能测试方法

Thu, 13 Oct 2022 17:11:12 CST

背景

最近打算用躺家吃灰的树莓派4B搭一个NAS，用来快捷方便地访问和备份一些资源。由于备选的硬件（芯片、硬盘、网线、路由器等）和软件（内网穿透技术）的技术选型比较多，这时候就需要有一个能简单评估服务性能的方法。因此简单搜寻了一下常见方案，方便在技术选型时有个统一的对比标准，并且对一些常见指标能在数量级上有一些感性的理解。

硬盘

对于硬盘的读写速度测试，首先我们需要注意根据读写的实现细节不同，测试出的结果会有很大的差别。例如对于读来说，是否走缓存读、缓存的大小如何；对于写来说，是否只写缓存、是否同步等待刷盘、刷盘的时机如何，等等。

在实际测试的时候一定要明确自己使用的是哪种IO模式，否则就会得到一些似是而非的结论。

设备查询

在测试硬盘前，我们首先得知道我们有哪些硬盘、分别对应哪些分区。用 lsblk （list block）命令可以查看当前机器下挂载的块设备：

  $ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 29.3G  0 disk
└─sda1        8:1    1 29.3G  0 part /media/pi/5615-BDE2
mmcblk0     179:0    0 59.5G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 59.2G  0 part /

可以看到，这里的 sda (SATA device a) 表示我外部插入的一个U盘；mmcblk0 (Multimedia card block 0) 表示树莓派自带的一张 SD 卡。这两个类型是 disk，也就是实体磁盘。

每个 disk 会被分成多个 partition，也就是这里的 sda1 和 mmcblk0p1、mmcblk0p2。每个 partition 又会 mount 到不同的文件夹下，用于在文件系统中进行访问。因此对于文件系统本身来说，我们只会关心到 partition 层面。

通过 df 命令我们也能直接观察到所有分区的挂载情况：

  $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        59G   11G   46G  19% /
devtmpfs        3.5G     0  3.5G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G   65M  3.6G   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   32M  221M  13% /boot
tmpfs           738M  4.0K  738M   1% /run/user/1000
/dev/sda1        30G   23M   30G   1% /media/pi/5615-BDE2

同时，disk 和 partition 的详细信息也可以通过 fdisk 命令查看：

  $ sudo fdisk -l
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x140cee6b

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 124735487 124203008 59.2G 83 Linux


Disk /dev/sda: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: ProductCode
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf3203eea

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1        2048 61439999 61437952 29.3G  7 HPFS/NTFS/exFAT

总之，在这里我们只需要搞清楚我们想测试的磁盘和分区分别是哪个即可。

hdparm

对于读性能测试，我们一般可以用 hdparm 工具（hard disk parameter? hardware device parameter?）。Debian下直接 apt 安装即可：

  $ sudo apt install hdparm -y

hdparm目前只支持磁盘读性能测试，提供了三种方式进行测试：

直接读内存： sudo hdparm -T [device] 。
带buffer读磁盘： sudo hdparm -t [device] 。
不带buffer读磁盘: sudo hdparm -t --direct [device] 。

以我的 mmcblk0 设备为例，跑出来结果分别如下（当然，每次测试建议跑多次取平均值，这里偷个懒）：

  $ sudo hdparm -T /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   1840 MB in  2.00 seconds = 921.43 MB/sec
 
$ sudo hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads: 130 MB in  3.04 seconds =  42.74 MB/sec
 
$ sudo hdparm -t --direct /dev/mmcblk0

/dev/mmcblk0:
 Timing O_DIRECT disk reads: 124 MB in  3.01 seconds =  41.17 MB/sec

显然，走内存读是飞快，不过对于测试磁盘性能来说没有任何意义；不带buffer看起来比带buffer要慢一点点，差别不太大；考虑到现实场景中大多数都是带buffer的读，因此我们在比较时用带buffer读的结果来进行参考即可。

dd

dd (data definition? data duplicator?) 是进行磁盘操作、文件生成之类的常用工具。在 gnu 的 coreutils 下，类 Unix 发行版几乎都自带。

写性能

一般我们会用 dd 来进行磁盘写性能测试，一般来说也有三种方式：

直接写内存： dd bs=1M count=256 if=/dev/zero of=test 。
使用内存做缓存写完后一次性刷盘： dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync。
使用内存做缓存，每写完一部分就刷一次盘： dd bs=1M count=256 if=/dev/zero of=test oflag=dsync。

还是以我的 mmcblk0 设备为例（当前目录即挂载的 mmcblk0 设备），跑出来结果分别如下（当然，每次测试建议跑多次取平均值，这里还是偷个懒）：

  $ dd bs=1M count=256 if=/dev/zero of=test
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 1.39574 s, 192 MB/s

$ dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 31.739 s, 8.5 MB/s

$ dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 39.694 s, 6.8 MB/s

$ rm test

可见写内存不sync的确还是快，不过还是没啥参考意义。考虑到实际情况下大部分程序都是采用 fdatasync 的模式来写，因此我们在比较时用这个数据即可。

读性能

当然，有人也会利用 dd 进行读性能测试，比如：

  $ sudo dd bs=1M count=256 if=/dev/mmcblk0 of=/dev/null
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 6.03649 s, 44.5 MB/s

看起来很美好，结果也和 hdparm 差不多。但是当你第二次再跑这个命令的时候，由于写缓存的存在，结果会快特别多：

  $ sudo dd bs=1M count=256 if=/dev/mmcblk0 of=/dev/null
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 0.267236 s, 1.0 GB/s

显然这样的测试是没有意义的。考虑到这种测试方法甚至很难做到幂等，这里还是不建议用 dd 来测试读性能。

小结

对于磁盘读性能测试，建议使用 sudo hdparm -t [device]。

对于磁盘写性能测试，建议使用 dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync。

网络

网速测试一般分两种，一种是测试当前设备对普通公网设备的读写速度；另一种是点对点测试两个服务器之间的速度。

speedtest

speedtest 工具在各地都有测速服务器，通过命令行（speedtest-cli）或者网页（https://speedtest.cn，https://speedtest.net）都可以进行网速上下行的测试。这里以命令行为例：

  $ sudo apt install speedtest-cli -y

$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from China Mobile (183.192.82.69)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Chinamobile-5G (Shanghai) [8.49 km]: 6.054 ms
Testing download speed................................................................................
Download: 128.24 Mbit/s
Testing upload speed......................................................................................................
Upload: 22.88 Mbit/s

虽然多次测试可能会访问到不同的测试点、导致结果有区别，不过其实也大差不差了。

在使用时偶尔会遇到返403，不要慌，多试几下一般就好了。

iperf3

如果我们并不是想测试公网网速，而是测试两个服务器之间点对点的网速。这时用 iperf3 工具就好。

  $ sudo apt install iperf3 -y # Debian 下
$ brew install iperf3        # MacOS 下

需要注意，除了 iperf3 之外，还有一个 iperf。这两个版本分别由不同组织开发，前后也不兼容。虽然似乎 iperf3 有坑，不过似乎功能多一点，尤其是支持了下行带宽测试（iperf 只支持上行带宽测试），所以这里还是用 iperf3。

iperf3 是 C/S 架构，服务端开启 server ，客户端开启 client，然后互相通信进行测速。以我在家的树莓派和一个在 HK 的 Azure 主机为例：

  $ iperf3 -s -p 5555                   # azure 主机上开启 server

$ iperf3 -c 104.208.65.181 -p 5555    # pi 上开启 client 并连接 server

测试完成后，client 上会有报告：

  $ iperf3 -c 104.208.65.181 -p 5555
Connecting to host 104.208.65.181, port 5555
[  5] local 192.168.1.2 port 35994 connected to 104.208.65.181 port 5555
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.68 MBytes  72.8 Mbits/sec    0   2.95 MBytes
[  5]   1.00-2.00   sec  1.25 MBytes  10.5 Mbits/sec  2018    252 KBytes
[  5]   2.00-3.00   sec  2.50 MBytes  21.0 Mbits/sec  1076    286 KBytes
[  5]   3.00-4.00   sec  3.75 MBytes  31.5 Mbits/sec  861    237 KBytes
[  5]   4.00-5.00   sec  2.50 MBytes  21.0 Mbits/sec   99    187 KBytes
[  5]   5.00-6.00   sec  1.25 MBytes  10.5 Mbits/sec    0    206 KBytes
[  5]   6.00-7.00   sec  2.50 MBytes  21.0 Mbits/sec    0    215 KBytes
[  5]   7.00-8.00   sec  2.50 MBytes  21.0 Mbits/sec    0    218 KBytes
[  5]   8.00-9.00   sec  2.50 MBytes  21.0 Mbits/sec    0    218 KBytes
[  5]   9.00-10.00  sec  2.50 MBytes  21.0 Mbits/sec    0    220 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  29.9 MBytes  25.1 Mbits/sec  4054             sender
[  5]   0.00-10.09  sec  26.5 MBytes  22.1 Mbits/sec                  receiver

iperf Done.

这里可以看出 client 对 server 的上行带宽大约是 22Mbit/sec。

类似的，server配置不变，client加上 -R 参数后可以测试出 server 对 client 的下行带宽：

  $ iperf3 -c 104.208.65.181 -p 5555 -R
Connecting to host 104.208.65.181, port 5555
Reverse mode, remote host 104.208.65.181 is sending
[  5] local 192.168.1.2 port 36000 connected to 104.208.65.181 port 5555
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  6.47 MBytes  54.3 Mbits/sec
[  5]   1.00-2.00   sec  25.7 MBytes   216 Mbits/sec
[  5]   2.00-3.00   sec  13.2 MBytes   111 Mbits/sec
[  5]   3.00-4.00   sec  16.3 MBytes   137 Mbits/sec
[  5]   4.00-5.00   sec  12.4 MBytes   104 Mbits/sec
[  5]   5.00-6.00   sec  14.4 MBytes   121 Mbits/sec
[  5]   6.00-7.00   sec  14.0 MBytes   117 Mbits/sec
[  5]   7.00-8.00   sec  13.9 MBytes   116 Mbits/sec
[  5]   8.00-9.00   sec  11.5 MBytes  96.7 Mbits/sec
[  5]   9.00-10.00  sec  11.3 MBytes  95.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.09  sec   142 MBytes   118 Mbits/sec  2560             sender
[  5]   0.00-10.00  sec   139 MBytes   117 Mbits/sec                  receiver

iperf Done.

这里可以看出 server 对 client 的下行带宽大约是 117Mbit/sec。

CPU&内存

sysbench

对于CPU和内存的性能测试，可以使用 sysbench 工具。

  $ sudo apt install sysbench -y # Debian 下
$ brew install sysbench        # MacOS 下

对于我的树莓派测试如下：

CPU单线程测试，可以看出单核每秒操作数大约1483：

  $ sysbench cpu --threads=1 run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1483.17

General statistics:
    total time:                          10.0002s
    total number of events:              14839

Latency (ms):
         min:                                    0.67
         avg:                                    0.67
         max:                                    1.88
         95th percentile:                        0.68
         sum:                                 9992.91

Threads fairness:
    events (avg/stddev):           14839.0000/0.00
    execution time (avg/stddev):   9.9929/0.00

内存读写测试，可以看出读写速度约是 1814MiB 每秒：

  $ sysbench memory run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Running memory speed test with the following options:
  block size: 1KiB
  total size: 102400MiB
  operation: write
  scope: global

Initializing worker threads...

Threads started!

Total operations: 18590983 (1858174.07 per second)

18155.26 MiB transferred (1814.62 MiB/sec)


General statistics:
    total time:                          10.0001s
    total number of events:              18590983

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    0.20
         95th percentile:                        0.00
         sum:                                 4463.57

Threads fairness:
    events (avg/stddev):           18590983.0000/0.00
    execution time (avg/stddev):   4.4636/0.00

需要注意的是，对 MacOS 的 CPU benchmark 似乎有坑，测试出来的结果异常的大，不具有参考价值。

md5sum

虽然 sysbench 的基准测试看起来比较靠谱，但是实际环境下，真正的执行效率还跟执行的指令啥的都有挺大关系。比如，我们以执行 md5 的速度来对比 CPU 的执行效率：

  $ dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.81996 s, 184 MB/s
cd573cfaace07e7949bc0c46028904ff  -

通过 dd 命令向 md5sum 持续发送 1GB 的数据进行计算，计算的速度也可以看成是 CPU 单核性能的一种指标。（考虑到管道操作是单线程，这个指令其实也只能用到一个核）

然后，如果我们多找几个 CPU 进行以下对比，我们就会发现一些神奇的现象：

Cortex-A72（ARM）

sysbench 单线程：1479.99 event/s
dd + md5sum：184 MB/s

Neoverse-N1（ARM）

sysbench 单线程：3497.70 event/s
dd + md5sum：424 MB/s

Intel(R) Xeon(R) Platinum 8171M CPU @ 2.60GHz（x86_64）

sysbench 单线程：820.19 event/s
dd + md5sum：409 MB/s

Intel(R) Xeon(R) CPU E5-26xx v4（x86_64）

sysbench 单线程：927.74 event/s
dd + md5sum：459 MB/s

Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz（x86_64）

sysbench 单线程：1054.30 event/s
dd + md5sum：515 MB/s

可以发现 ARM 架构的机器在 sysbench 上表现几乎都比 X86_64 的机器好很多，但是实际跑 md5sum 却相差不大甚至差不少。

可见不同架构间二者的指标并不完全正相关；不过相同架构间二者的指标还是基本正相关的。

参考资料

dd-benchmark

man-hdparm

iperf

中台工具产品方法论

Thu, 28 Apr 2022 17:50:15 CST

背景

做中台工具产品不是一件容易的事情，需要对接上层所有业务方，做的慢业务方不满意，做的快业务方未必会给好的评价。

属于容易背锅，细节极其多，用户反馈建议多，但又难以出成绩和证明自己做的好。

场景

虚构一些场景，大家肯定都遇到过。

场景1

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下。

几天之后……

老板：XX和XX等N个功能都不错，马上排期做下。

产品经理：收到。

评价：产品经理是初级的工具人，执行命令，最终老板大概率不会满意，因为产品功能都是老板自己提的，上线未必效果好。

老板会认为自己是个有想法的人，同时认为产品经理没有想法，产品经理挺冤枉，干的比黄牛累。出了成绩是老板高瞻远瞩，没有成绩是没执行好。

对话通常以被动接受信息，缺乏有效的反馈和互动。收集大量需求导致执行慢，可能会被技术同事认为是战斗力等于5的渣渣。

场景2

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下…（几小时之后）这个功能挺好，和技术同事工作量比较大，会在下一个版本中增加。

评价：高级工具人，收到信息之后，能够给予执行的时间点，对工作量和项目节奏有一定把控能力。

场景3

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，用户给我们反馈过，XX竞品也有这个功能。我们已经在当前规划中了，计划在下一个版本中增加。

评价：有一定自主工作意识，对产品有一定思考，老板只是信息源之一，能从用户反馈和竞品等渠道提炼产品需求，有主动找信息和需求的能力。但很少反驳别人的想法，对事情的优先级把控能力还不够。

场景4

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，会放在下一个版本中增加。我们当前版本是主要提升另外一个模块的易用性，用户意见比较大，是影响产品NPS的主要因素，上线之后预期会影响xx%比例的用户。而你提的XX功能属于体验优化，我们会在下一个版本中迭代。

评价：有优先级掌控意识，在和老板的对话中体现了自身的专业性，体现了用户反馈、NPS和数据来驱动产品迭代，在产品标准上和老板拉齐认知。产品的目的在于提升NPS等，不局限于讨论某个功能点。即使拒绝了老板需求，老板也会认为产品经理有自己的思考。

但是缺陷在于，产品经理的眼光只能看到未来1-2个月的规划，对长期规划还缺乏把控。

场景5

老板：XX功能我觉得不错，做了吗？

产品经理：已经在规划当中了，房产中介对这个需求有很强需求，而其他类型的用户需求不高。我们今年的目标是满足电商等前5的用户诉求，这些行业对公司贡献大，我们最近做了调研发现电商等用户对XX功能有很强的诉求，提炼了N个需求来，比如XX……

评价：对全局有掌控，对公司战略目标有理解，基于战略目标拆解出了自己的目标，能够主导项目迭代。

老板满意，合作方满意，技术同事跟着干活能自己做事情的价值，对产品经理认可度很高，不会带着项目组做无用功。

场景6

老板：XX功能我觉得不错，做了吗？

产品经理：需求可以做，功能产品侧都可以做，细节是永远做不完的，但是缺乏方向性。我认为SaaS产品的核心目标是收入，当前提升收入的抓手我们还没有明确。通过数据分析、用户访谈和专家访谈，我觉得有xx场景是可以深挖的，这些行业还有50%+增量收入，期望与其他团队能联动在未来半年中达成这项目标。而你提的XX功能，不是典型的应用场景。

评价：这样的产品经理已经可以做业务负责人了，有完善的方向判断能力和产品方法论，有能力带领项目组走向成功。

而老板是资源，说服老板投入更多精力在某个方向，老板会对产品经理更为信任，提功能细节的次数会很少，更多是讨论项目方向，输入外界信息来帮助产品经理做判断。

做产品，超出用户预期，他们才会满意。做产品经理也是一样，认知超越周围的同事，大家才会认可你。

有效管理的启发式方法

Thu, 14 Apr 2022 10:32:14 CST

原则

偏向于行动和决策，而不是计划和共识。
喜欢写作胜过会议。
了解您的产品如何在野外使用。例如，加入销售和支持电话。
通过专注于您想要实现的结果来向后工作。
通过提出开放性问题来鼓励所有权。
成为啦啦队长。经常庆祝成功并加强积极的行为。
知道如何区分可逆和不可逆的决定。
确保每份报告都了解团队、组织和公司的首要任务。
经理之下没有任何任务。即使它不是编码，也要弄脏你的手：

一对一

永远不要跳过一对一。这是接收和提供反馈的最佳平台。大多数队友重视它，通常当他们不重视它时，是因为他们没有看到一个表现得很好。
争取每周一对一。
关注5个主题：
- 可预测性：创建例行程序、设定期望、使变化正常化。
- 所有权：提供选择，明确所有权，赋予更多责任。
- 目的：阐明其任务的全局价值和重要性。
- 进步：创造里程碑，分享胜利，庆祝进步。
- 归属感：团队文化与管理。
帮助构建每个主题的问题。“在 1-10 的范围内，您如何评价：...”
- 可预测性：你对你的期望有多清楚？
- 所有权：您对决策权和方向的满意度？
- 目的：你的工作对团队有多大影响？
- 进步：每周进步的感觉？
- 归属感：你与团队的联系感？
不经常提出的其他问题：
1. 动机：
  1. 你工作的哪个部分最有趣？
  2. 在这里工作有什么不开心的？
  3. 你每周最大的时间浪费是什么？
2. 长期目标：
  1. 你想提高什么技能？
  2. 你在寻找什么样的职业道路？
  3. 您会很高兴向公司中的谁学习更多信息？
  4. 您希望更多地参与业务的哪些部分？
3. 组织意识：
  1. 您不喜欢该产品的哪些方面？
  2. 我们错过的最大机会是什么？
  3. 您认为本季度的三大优先事项是什么？球队的？组织的？
  4. 如果你是 CEO，你会做些什么不同的事情？
4. 经理的角色：
  1. 我能做些什么来更好地支持你？
  2. 如果你是我，你会改变 1 到 3 件事是什么？
  3. 您如何看待收到的反馈数量？
  4. 我需要反馈。我可以做哪些不同的事情？
  5. 我们可以做些什么来改善我们的协作方式？
5. 优先事项：
  1. 本周你的首要任务是什么？
  2. 成功会是什么样子？
  3. 什么是障碍？
鼓励您的直接下属提出主题：
有关有效的一对一的更多想法，请参阅从一对一中获得更多。
没有一种最好的管理风格。在您最初的一对一中弄清楚某人希望如何被管理：
1. 你喜欢你的前任经理什么？你不喜欢什么？
2. 你喜欢从经理那里看到什么？
报告也是经理的一对一通常更“业务”，重点是战略、团队健康和项目一致性。

辅导

默认为开放式问题：以what、how、who而不是像do、have那样的封闭式问题开始提问，是邀请对话并赋予问题所有权。
- “你有什么问题？” 比“你有什么问题吗？”更好。
- “为什么你认为这是正确的做法？” 比“这是个好主意吗？”更好。
- 回答“到目前为止你的想法是什么？” 当被问到“我该怎么办？”
总结这个人在说什么，这样你们就可以在同一页面上并找出问题所在。
- “听起来有两个问题，x 和 y。我们应该先关注哪个？”
弄清楚如何使会议富有成效：
- “下一步是什么？”
- “我们应该如何追踪这个？”

回馈

要及时，最好在提示事件的同一天提供反馈。
通过提供上下文来获得关于提供反馈和减少神秘感的支持：
- “你有10分钟吗？” ⛔️
- “你有 10 分钟的时间来谈谈今天早上的站立会议吗？”
- “我可以和你分享一些关于我们如何合作的想法吗？”
不要以赞美开头来填充负面反馈；它给出了混合的信号。
即使是积极的反馈，也要具体。
- “做得好！” ⛔️
- “我喜欢你为减少服务的内存占用而采取的举措。它鼓励我给你更多的所有权，这样我就可以专注于其他地方。”
关注数据而不是行为：
- “我注意到你没有解决你最近三个 PR 中的任何评论”
- “我注意到你没有拿起我让你做的票”
- “我注意到您的上一个功能版本没有经过任何测试”
- “你的代码有问题” ⛔️
- “你总是迟到” ⛔️
谈论为什么这很重要以及它正在影响谁：
- “我提到它是因为我们作为一个团队工作很重要”
- “我提到它是因为我分配给你的票对本季度的路线图至关重要”
一起找出解决问题的方法：
- “你觉得我们的流程怎么样？”
- “你怎么看？”
就行动计划达成一致：
- “我们如何确保下次不会错过机票到期日？”
- “你现在可以采取哪些行动？”
- “我们的行动项目是什么？”
突出积极模式（记住要具体）。
- “很高兴看到你教 X 关于 Y，让他们和你一样精通。这是高级工程师的特质。”
重播本能反应以帮助构建对话：
- “我对你的提议的最初反应是……”
- “这就是我会做的”比“这是你应该做的”更好
- “当你做 X 时，我感觉到了 Y”

战略性思考

再多一个人怎么办？
你的团队是如何推动针的？你专注于正确的事情吗？您如何知道您正在构建的功能将使客户受益？
你的产品的使命和宗旨是什么？
你的团队士气如何？你有没有问过他们在这里工作有什么不好玩的？
公司今年的首要任务是什么？三年后公司应该在哪里？
本季度您的“岩石”和“卵石”项目是什么？
您的团队在推动什么公司年度目标？以什么方式推动？
如果你升职了，你的团队中谁会接替你的位置？这个人需要获得什么技能或经验？
你团队的痛点是什么？你怎么能快 2 倍？
没有你，你的团队能运作多少？
如果公司失败了，最可能的原因是什么？
你担心什么 “狗不叫” ？

做出决定

确定决策是可逆的还是不可逆的。
- 可逆的决定很容易被改变。示例：更改站立时间、提供指导。
- 如果不进行大量返工，就无法更改不可逆转的决定。这些决定应该花费更长的时间并记录在案并进行讨论。示例：架构变更、招聘、组织变更、数据模型。
- Sam Newman的技术决策准则：
每当出现分歧时，请关注决策的预期结果，并确保团队了解您的推理。
- “虽然数据库 X 更好，但我希望我们在一个堆栈上进行标准化，以便更容易维护。”
如果有人不同意一个可逆的决定，请设定一个日期与团队重新讨论该决定。理想情况下，您还有衡量该决策成功与否的指标。
- “我理解你的担忧。让我们在一个月后重新审视这个问题，看看我们的立场。”
- “我们现在正在跟踪 X，如果它随着这些变化而有所改善，让我们在下个季度重新审视。”
如果有人不同意不可撤销的决定，请给他们机会陈述他们的观点。无论如何，每个人都应该知道决定最终是你的，团队需要不同意并完全致力于所做的决定。
记录您的决定，以便您可以参考做出这些决定的原因以及您的团队面临的权衡。

编码

避免在关键路径中编码。来自慈善专业的提示：

创作功能？ ⛔️
在有人需要休息时提供随叫随到的服务？ ✅
验尸后潜入最大的项目？ ⛔️
代码审查？ ✅
发现一个令人讨厌但似乎从未成为首要任务的 p2 错误？ ✅
坚持所有提交都必须获得批准？ ⛔️
清理监控检查并编写库来生成覆盖率？ ✅

票务和公关流程

为团队制定贡献指南。
PR 应该足够小，可以在一小时内得到适当的审查。
优先考虑 PR 以取消阻止票证。
使用 linting 或代码格式化程序（如 black ）自动处理诸如 style 之类的意见。

沟通

写作

赞成长篇写作提案而不是演示文稿。写作迫使作者思考细节和权衡。
喜欢枚举列表而不是项目符号列表；它们更容易参考。
鼓励亚马逊式的 “6 寻呼机”和“2 寻呼机”。
创作音乐。
例子：
1. 是时候建造了
2. 我们不在这里卖马鞍

电子邮件

[Action Required]如果您希望读者采取行动，请在主题前加上前缀。
按以下方式构建您的电子邮件（来自 7 Tips for Better Executive Communication）：
1. 第一段——不超过两句话。这将是标题和关键信息
2. 第二段 - 3-7 个项目符号。项目符号越多，行长越短。旨在不换行。
3. 第三（最后）段——不超过 2-3 个句子，重点关注所需的行动、后续行动和时间表。
在工作时间之外“安排发送”电子邮件，除非它们只是仅供参考或您需要立即回复。

会议

通过鼓励在开会前提出建议来避免糟糕的头脑风暴会议。

“不要将决定推迟到会议上。当场做出决定，通过长篇写作进行沟通，并利用会议进行讨论。” ——埃里克·伯恩哈德森
避免没有固定议程的同步或重复会议。
总是以行动、所有者和时间结束会议，因此很清楚下一步是什么。
对于员工会议，绕过桌子询问报告他们最关心的问题是什么。

许多经理想参加行政人员会议，因为这让他们感到被需要并让他们知道。我通过设定会议入场费来利用这种愿望：你必须承认至少有一件事情“着火了”。”——本·霍洛维茨
偶尔向与会者询问会议是否富有成效或如何改进是值得的。
在发送邀请之前，问问自己为什么不能通过电子邮件传达此会议。

招聘

如果您可以“招聘强硬”，您就可以“轻松管理”——Sue Tetzlaff，《员工体验》

招聘是经理做出的最重要的决定。

在高级工程师中寻找什么：

所有者。即使不是 100% 的责任，也要对问题负责；明白为什么。
1. “告诉我你有一次在你的职责范围之外承担了一些重要的事情。为什么它很重要？结果是什么？”
2. “告诉我你曾经为了长期目标而做出牺牲短期收益的艰难决定的经历。”
处理歧义
1. “你能告诉我你必须解决一个雄心勃勃的问题的时间吗？为什么这个问题很重要？”
2. “你能告诉我你在没有完整信息的情况下不得不做出决定的时候吗？当时的情况是什么？你冒了哪些风险？你为什么做出你做出的决定？”
团队球员。很好地接受反馈。
1. “告诉我你对某件事改变主意的时候。你背后的思考过程是什么？”
2. “说说你和你的经理意见相左的时候吧。你从这种情况中学到了什么？”
3. “说说有一次你需要一个抗拒的同伴合作。你做了什么？结果如何？”
4. “给我一个你收到的艰难或批评反馈的例子。它是什么，你做了什么？”
5. “如果我要和你的同龄人交谈，他们会对你有什么正面或负面的反馈？”
沟通者。可以表达不同层次的想法。
1. “什么造就了伟大的工程师？”
2. “向我描述一些你很熟悉的事情。”
3. “你在简历中提到了X，给我解释一下，就好像我从来没有遇到过一样？”
老师。喜欢培养其他工程师。对于高级工程师尤其重要。
1. “告诉我你曾经帮助团队中的某个人成长的经历。”
深潜者。深入挖掘一个级别以了解幕后发生的事情。
1. “告诉我有一次你试图了解团队中的一个问题，但你必须深入多层才能弄清楚。”
简化。简化问题，而不仅仅是破解事物并增加技术债务。该人是否有构建与购买的心态。
1. “告诉我一个你用简单解决方案解决的复杂问题。”
传教士。对公司的使命或技术感兴趣。
1. “向我解释一下你现在的公司做什么以及为什么它很重要。”
2. “你在[公司]工作有什么兴趣？”

需要注意什么：

在公司短期任职。如果候选人通常在公司呆不到一年，请询问他们为什么。可能有完全正当的理由，或者它可能表明该人难以使用的模式。
1. 为什么你只在 X 工作了不到 1 年？
技术菜单。仅列出使用的技术而不是解决的问题的简历可能表明人们可能没有考虑全局。也是初级工程师的典型特征。
长简历。超过 2 页可能表明该人难以提炼出重要的内容。话虽如此，长简历可能有文化原因。例如，在一些欧洲国家，鼓励简历要长。

入职

拥有良好的入职流程对于团队的成功至关重要。它确保新成员尽早做出贡献，并融入您的流程和文化。

如果您的新团队成员可以在他们加入的第一天提供错误修复，则入职流程是成功的。

入职材料：

团队使命
1. 您的团队如何为客户提供帮助？
团队成员
1. 包括：姓名、角色/职务、电子邮件、slack 用户名、github 用户名
存储库和服务
团队内部如何沟通
1. 松弛通道
2. 让自己了解情况
3. 工作时间内外的通信协议
文档
1. 代码贡献指南
2. 公关审查流程
3. 票务流程
4. 专业术语
5. 发布代码
6. How tos（例如迁移数据库，添加机密）
入门
1. 安装说明（例如 Docker、postgres）。
2. 所有预期访问的清单（例如 AWS、PagerDuty）
3. 在本地运行您的应用程序
4. 部署您的第一个错误修复
会议。您的新团队成员应该与谁见面？

向上管理

通过共享列出您的项目优先级、时间表和信心水平的文档，确保您和您的经理在同一页面上。
你的经理也需要向上管理。主动向您的经理通报项目时间表的变化，简要回答以下问题：
1. 新的时间线是什么？
2. 为什么时间线发生了变化？
3. 你对新的时间表有多自信？
没有人在乎责备或借口。自己的错误并记录您将采取的纠正措施以减轻它们的影响。

横向管理

通过提出问题而不是解决方案来获得支持。
1. “对我们来说，做功能 X 的最佳方式是什么？”
2. “我需要你做 X，这就是方法”⛔️
要求制定时间表，让您的同行对交付日期负责。
如果您不同意某个方法，请记录您的疑虑。拥有审计跟踪可以提高问责制。
创建项目启动和站立，以确保您了解其他团队的状态和优先事项。

宣布改变

变革的例子：升职、改组、重组。
承认改变的困难或机会。
通过使用叙述来解释原因来吸引情绪。
1. 为什么现在这种变化对公司很重要？
2. 这种变化对谁有影响？
用事实诉诸逻辑。
1. 这种变化将实现哪些指标？
将改变社会化以获得支持。
1. 从受影响最大的人开始。
例子：
1. Carta 的 covid-19 裁员

进一步阅读

亚马逊领导力原则：围绕领导力运作的最佳原则。
经理之路：各级管理的优秀指南。
每个工程经理都应该知道的 97 件事：收集来自不同从业者的管理技巧。
每个工程经理都应该问自己的 5 个问题
钟摆或阶梯：关于成为一名想要保持技术的经理所面临的挑战。
Hard Thing About Hard Things : 更多在行政层面，但仍然值得。
你所做的就是你是谁：为什么公司文化很重要以及如何建立一种文化。
工程管理回购：管理文章的大集合。
招聘工程领导者：招聘工程领导者。
如何比市场更聪明地招聘：伯克森的悖论和工程招聘。
LifeLabs 学习。适合新手和经验丰富的经理的绝佳研讨会。我从中学到了很多关于反馈、指导和 1-1 的知识。
软件工程师如何帮助面试他们未来的经理：工程师在面试经理时要问的问题列表。
从一对一中获得更多：如何衡量成功的一对一。
更好的执行沟通的 7 个技巧：关于如何有效沟通的技巧。
有毒的会议文化：如何避免遇到反模式。

大聪明教你学Java | 为什么不能使用 BigDecimal 的 equals 方法做等值比较

Sat, 29 Jan 2022 03:57:03 CST

前言

BigDecimal 是 java.math 包中提供的一种可以用来进行精确运算的类型。所以，在支付、电商等业务中，BigDecimal 的使用非常频繁。而且其内部自带了很多方法，如加，减，乘，除等运算方法都是可以直接调用的。除了需要用 BigDecimal 表示数字和进行数字运算以外，代码中还经常需要对于数字进行相等判断。

说到等值比较，咱们先看看《阿里巴巴Java开发手册》中的要求：那么为什么会有这样的要求呢~ 其中的奥秘是什么呢~ 请各位小伙伴听我娓娓道来...

BigDecimal 做等值比较

      public static void main(String[] args) {
        BigDecimal bigDecimal1 = new BigDecimal(1);
        BigDecimal bigDecimal2 = new BigDecimal(1);

        if(bigDecimal1 == bigDecimal2){
            //等值比较
        }
    }

相信聪明的小伙伴一眼就可以看出来上面的代码是有问题的，因为 BigDecimal 是对象，不能使用 == 来做等值判断。

如果我们使用 BigDecimal 的 equals 方法做等值比较是不是可以呢？

      public static void main(String[] args) {
        BigDecimal bigDecimal1 = new BigDecimal(1);
        BigDecimal bigDecimal2 = new BigDecimal(1);

        if(bigDecimal1.equals(bigDecimal2)){
            //等值比较
        }
    }

这里我先卖个关子，咱们跑跑代码来看看能不能用 BigDecimal 的 equals 方法做等值比较(●'◡'●)，

      public static void main(String[] args) {
        BigDecimal bigDecimal1 = new BigDecimal(1);
        BigDecimal bigDecimal2 = new BigDecimal(1);
        System.out.println(bigDecimal1.equals(bigDecimal2));

        BigDecimal bigDecimal3 = new BigDecimal(1);
        BigDecimal bigDecimal4 = new BigDecimal(1.0);
        System.out.println(bigDecimal3.equals(bigDecimal4));

        BigDecimal bigDecimal5 = new BigDecimal("1");
        BigDecimal bigDecimal6 = new BigDecimal("1.0");
        System.out.println(bigDecimal5.equals(bigDecimal6));

    }

我们可以发现，在使用 BigDecimal 的 equals 方法对 1 和 1.0 进行比较的时候：使用 int、double 定义 BigDecimal 结果是 true；使用 String 定义 BigDecimal 结果是false，为什么会出现这种情况呢？

我们一起来看看 equals 方法的源码

  /**
     * Compares this {@code BigDecimal} with the specified
     * {@code Object} for equality.  Unlike {@link
     * #compareTo(BigDecimal) compareTo}, this method considers two
     * {@code BigDecimal} objects equal only if they are equal in
     * value and scale (thus 2.0 is not equal to 2.00 when compared by
     * this method).
     *
     * @param  x {@code Object} to which this {@code BigDecimal} is
     *         to be compared.
     * @return {@code true} if and only if the specified {@code Object} is a
     *         {@code BigDecimal} whose value and scale are equal to this
     *         {@code BigDecimal}'s.
     * @see    #compareTo(java.math.BigDecimal)
     * @see    #hashCode
     */
    @Override
    public boolean equals(Object x) {
        if (!(x instanceof BigDecimal))
            return false;
        BigDecimal xDec = (BigDecimal) x;
        if (x == this)
            return true;
        if (scale != xDec.scale)
            return false;
        long s = this.intCompact;
        long xs = xDec.intCompact;
        if (s != INFLATED) {
            if (xs == INFLATED)
                xs = compactValFor(xDec.intVal);
            return xs == s;
        } else if (xs != INFLATED)
            return xs == compactValFor(this.intVal);

        return this.inflated().equals(xDec.inflated());
    }

其实咱们从方法的注释中就能找到答案： equals 方法会比较两部分内容，分别是值（value）和标度（scale），也就是说 bigDecimal5 和 bigDecimal6 的值虽然相同，但是标度是不一样的。

咱们打个断点，debug 一下看看~

我们可以看见 bigDecimal5 的标度值是0，而bigDecimal6的标度值是1，所以 bigDecimal5 和 bigDecimal6 的比较结果是false (●ˇ∀ˇ●)

那么这时候又产生了一个疑问：为什么标度不同呢？

嘻嘻~ 各位小伙伴稍安勿躁，请听我娓娓道来~

BigDecimal 一共有以下 4 个构造方法：

BigDecimal(int)
BigDecimal(double)
BigDecimal(long)
BigDecimal(String)

其中最容易理解的就是 BigDecimal(int) 和 BigDecimal(long)，因为是整数，所以标度就是 0 （源码如下）：

  /**
     * Translates an {@code int} into a {@code BigDecimal}.  The
     * scale of the {@code BigDecimal} is zero.
     *
     * @param val {@code int} value to be converted to
     *            {@code BigDecimal}.
     * @since  1.5
     */
    public BigDecimal(int val) {
        this.intCompact = val;
        this.scale = 0;
        this.intVal = null;
    }

  /**
     * Translates a {@code long} into a {@code BigDecimal}.  The
     * scale of the {@code BigDecimal} is zero.
     *
     * @param val {@code long} value to be converted to {@code BigDecimal}.
     * @since  1.5
     */
    public BigDecimal(long val) {
        this.intCompact = val;
        this.intVal = (val == INFLATED) ? INFLATED_BIGINT : null;
        this.scale = 0;
    }

而对于 BigDecimal (double) 来说，当我们使用 new BigDecimal (0.1) 创建一个对象的时候，其实创建出来的对象的值并不是等于0.1，而是等于0.1000000000000000055511151231257827021181583404541015625 我们再打个断点，debug一下看看标度值是多少我们可以看到标度值是55，这个值是怎么来的呢？其实很简单，这个标度值就是这个数字的位数，其他的浮点数也同样的道理。对于 new BigDecimal (1.0)，和new BigDecimal (1.00) 这样的形式来说，因为他本质上也是个整数，所以他创建出来的数字的标度就是0。

最后我们再看看 BigDecimal(String) ，当我们使用 new BigDecimal ("0.1") 创建一个 BigDecimal 的时候，其实创建出来的值正好就是等于 0.1 的。那么他的标度也就是 1；如果使用 new BigDecimal ("0.10000")，那么创建出来的数就是 0.10000，标度也就是 5。

讲到这里相信各位小伙伴也明白了为什么 bigDecimal5 和 bigDecimal6 用equals 方法做等值比较的结果是false了 O(∩_∩)O

如果我们只想判断两个 BigDecimal 的值是否相等，那么该如何判断呢？

在 BigDecimal 中也为我们提供了一个方法 —— compareTo 方法，这个方法就可以只比较两个数字的值，如果两个数相等，则返回 0。我们把 equals 换成 compareTo 后可以发现，bigDecimal5 和 bigDecimal6 等值比较的结果是0，也就是说明这二者的值是相等的。

P.S. 所以我们在做等值比较的时候不要随便用 BigDecimal 的 equals 方法，如果只是要对数值作比较，就果断选择 compareTo 方法就搞定拉~

小结

本人经验有限，有些地方可能讲的没有特别到位，如果您在阅读的时候想到了什么问题，欢迎在评论区留言，我们后续再一一探讨‍

希望各位小伙伴动动自己可爱的小手，来一波点赞+关注 (✿◡‿◡) 让更多小伙伴看到这篇文章~ 蟹蟹呦(●'◡'●)

如果文章中有错误，欢迎大家留言指正；若您有更好、更独到的理解，欢迎您在留言区留下您的宝贵想法。

爱你所爱行你所行听从你心无问东西

竞品分析7000字方法论——7个视角，50+维度，附赠竞品思维下的撩妹技巧

Tue, 19 Oct 2021 08:54:38 CST

知彼知己，百战不殆。

——《孙子兵法》

产品经理的岗位职责之一是在市场中建立和维护产品的竞争优势，竞品分析是产品经理的一项常规工作，分析质量决定着决策质量，影响着对业务取长补短的效果。

但在竞品分析时，常遇到以下问题：

没有养成日常习惯，分析时无从下手
企图以此寻找需求或印证自己的观点
由领导发起，找模板套公式，交作业
分析维度杂乱浅显，结论无参考价值

那么，竞品分析应该怎么做呢？

当我刚刚喜欢上一个姑娘时，却发现已经有人喜欢她了，而且张三已经表白，李四也有好感，怎么办呢？

大脑会在荷尔蒙的牵动下情不自禁做起了分析和策略。先从人类视角思考一下世界观、人生观、价值观、婚恋观，确定一下自己要谈一场什么样的恋爱。再从恋爱角度来了解姑娘，哪里人呀？啥家庭呀？啥衣食住行呀？啥爱好？啥性格呀？符合梦中情人的样子么？这么一通观察下来，那多久约一次会、吃什么饭、唱什么歌、送什么礼也就心里有数了。张三李四都干啥了就得有差异化。进一步了解之后又要返回到婚恋观，问自己真诚否？关系合适否？只有对自己真诚，对姑娘真诚才能情投意合。既然双方感觉都不错，继续更深一步互动，少了一些遮掩，偶有矛盾，知道双方喜欢啥，雷区是啥。如此，言谈举止便要有所分类，分类即尊重，相容即相爱。咔，到这里，没有张三李四的事了。良久，两人有了结婚的想法，要双方家长见面聊聊呀，聊聊两个大家庭的想法，聊聊小家庭的打算，真心地切合实际地聊。靠谱！咔，姑娘到手。结婚的过程又一次巩固了小家庭的使命、愿景、价值观，那就过日子吧。总之，在与姑娘相处的每个阶段、每个事上都要真诚以待。

竞品分析更是如此了。要与用户谈恋爱。

当然，更准确地来说是竞争分析，产品只是价值的载体。

做一款产品时，却发现已经有直接竞争者、替代竞争者、潜在竞争者、预算竞争者了，而且还有一些可参考的友商。就从7个角度观察分析：

从上帝视角看市场，了解产业和行业的运作模式、所处环境和市场数据，便于筛选目标市场；
从市场角度看用户，了解目标市场中全部用户的分层及画像，便于筛选目标用户；
用研发角度看产品，了解开发生命周期中的差异；
从市场角度看产品，了解产品生命周期中的差异；
从产品角度看用户，了解产品中存量用户的细分，便于精细化运营；
从用户角度看产品，了解用户不同的体验和评价；
从产品背后看企业，了解竞争者的资源配置情况；

在频率上可以日常分析、定期分析、突发性地专项分析；在分析粒度上可以大到对行业趋势的分析，中到对竞品方案的分析，小到对竞品功能点的分析；在呈阅对象上，可以是BOSS、PM、设计师、研发人员等。

总之，PM做竞争分析时要在产品所处的每个阶段、工作的每个细节上都真诚以待，这样才能得到客观有用的结论。这是对竞品分析的工作思想。

开始分析吧！

分析目的有哪些？
分析对象有哪些？
分析角度有哪些？
竞品信息的来源有哪些？
竞品信息的处理流程有哪些？
分析方法有哪些？
结论如何呈现？

一、7个分析目的

用户价值、商业价值、用户价值与商业价值间平衡，这三类的预期和现状之间有所差距，想找到解决方案减少差距呗，那还是会遇到7种不同的情况：

知道差距，没方案，寻找方案
知道差距，有方案，不知道方案对不对
知道差距，有方案，不知道方案如何实施
知道差距，有方案，但方案行不通，咋办
知道差距，多种方案，不知道选择哪个最好
知道现状不是想要的，说不清预期，没方案
知道预期就是想要的，不清楚现状，没方案

往细来说，大概会在开拓市场时，寻找市场切入点、寻求差异化、规划业务、策划运营方案等；在挖掘用户需求时，分析用户和分析需求等；在观测市场时，做行业预测、竞争预测等；在......时，进行......

二、5个分析对象

以“目标用户类型”、“核心需求”、“产品或服务的特征”和“用户购买预算”为依据大致可以划分为5类竞品。

★代表相似，✘代表不同，- 代表可有可无

三、7个分析角度

3.1、从上帝视角看市场

从整体上看，市场的构成如下图要素构成。在这个视角，我们主要做产业分析、行业分析和市场分析。

3.1.1、产业分析

产业是指由利益相互联系的、具有不同分工的、由各个相关行业所组成的业态总称。一个产业可以跨越（包含）几个行业。

产业结构、产业分类、技术结构、技术分类一般都有国际或国家的分类标准，百度可见；其中产业结构中各角色的互动关系如下图所示：

图中的互动关系也可称之为“产业链”中的“供需链”。

产业布局是指产业在一国或一地区范围内的空间分布和组合的经济现象。在静态上看是指形成产业的各部门、各要素、各链环在空间上的分布态势和地域上的组合。在动态上表现为各种资源、各生产要素甚至各产业和各企业为选择最佳区位而形成的在空间地域上的流动、转移或重新组合的配置与再配置过程。可用“产业地图”来表示：

示例一：按资源、生成要素的流动展示

图中的流动关系也可称之为“产业链”中的“价值链”，而完整的价值链如下图：

示例二：按在各产业和各企业的流动展示

图中的企业关系也可称之为“产业链”中的“企业链”。

示例三：按地理空间展示

图中的地理关系也可称之为“产业链”中的“空间链”。

汇总一下，对产业的了解可从时间、空间和程度三个方面来研究，如图所示：

3.1.2、行业分析

行业指一组提供同类相互密切替代商品或服务的公司。选定行业就一定能看到我们的竞争者有哪些。从供需关系上看，就是研究目标市场的供给侧的生产者有哪些？

当然了，分类的话，还是分为竞争分析的5个对象。

那么，对行业分析，有哪些维度呢？

（1）生命周期。即老生常谈的引入期、成长期、成熟期、衰退期。

（2）竞争类型。分为完全竞争、垄断竞争、寡头竞争和完全垄断。

（3）行业要素。分析一个行业的主要影响要素及要素密集度。包括五类：

资本型，如房地产
技术型，如制造业
劳动型，如防治业
知识型，如创意设计
资源型，如煤炭、发电

（4）经济周期。分为三类：

增长型，如人工智能、云计算、物联网
周期型，如钢铁、煤炭、金融产品
防守型，如医药、旅游、家电

（5）行业结构。常从三个维度分析：

各产品的市场规模及结构变化
各地区的市场规模及结构变化
各消费群体的规模及结构变化

（6）主要数据。行业的发展分析时经常回顾历史、分析现状和预测未来。回顾、分析和预测哪些数据呢？主要有市场规模、毛利率、销售增长率和净资产收益率等。

3.1.3、市场分析

市场泛指商品交换的领域。

（1）分析对象:

针对产业做分析
针对行业做分析
针对企业做分析

（2）分析范围：

全局的
细分的

（3）市场概览：

过去近十年的数据：市场规模、GDP占比、复合增长率（GAGR）、线上化率（=线上市场规模/总市场规模）
现状分析：宏观环境因素分析（PEST）、对标其他国家和相近行业
判断未来趋势：数据拟合预测

（4）市场集中程度：

CRn（concentration ratio），n一般用10。也就是在这个市场市占前10的公司，加起来的总和占整个市场的百分比，百分比越高，证明这个市场的集中度也就越高。

（5）市场消费模式：

价格型
理智型
冲动型
想象型
习惯型
随意型

（6）上下游市场分析：

上游：政策、上游原材料构成、原材料价格走势、主要供应企业的供应量；
下游：政策、下游消费市场构成、消费市场结构变化趋势、主要消费群体的消费量；

（7）市场数据：

规模
- 市场整体规模
- 线上市场规模
- 我司市场规模（市场占有率）
数据
- 量（用户数）：下载量、注册量、活跃用户量、付费用户量等
- 次（订单数）
- 额（交易额）
- 利（营收、毛利润、净利润）
- 率（转化率、毛利率、增长率、净资产收益率）
趋势
- 增长
- 持平
- 下降

~~ ~

3.2、从市场角度看用户

从供需上看，就是研究目标市场的需求侧的消费者有哪些，该角度一般是在做新产品前对所有的消费者进行研究。

（1）分析对象：

目标市场中的消费者

（2）分析目的：

消费者分层，即市场细分，或是叫用户分层
找准目标用户

（3）分析范围：更多是全局分析

（4）分析方法：定性调研：

访谈、焦点小组、卡片分类、参与式设计
定量调研：调查问卷
场景调研：分为三类场景
- 用户场景：用户遇到问题、产生想法，发现解决方案的场景
- 使用场景：用户使用产品时的场景
- 营销场景：用户看到产品、选择产品、购买产品时的场景

（5）分析维度：

口碑调查：
- 口碑结构
- 口碑的地域性差异
- 品牌满意度
- 净推荐值
产品价格：客户希望为这个产品支付多少钱？竞品价格如何？
购买动机，购买的影响因素及比重
购买习惯，如购买渠道、购买时段等等
产品感知及体验

（6）分析产出：

产出一：用户故事版，或是用户画像之User Persona

产出二：价格分析图

产出三：满意度和净推荐值

产出四：购买因素及比重

产出五：购买习惯

~~ ~

3.3、用研发角度看产品

想要了解竞品是如何研发出来的，就需要关注和比较双方的开发什么周期的各个动作。要“比、学、赶、超”不断迭代，当然也要“你打你的，我打我的”，坚持自己得定位。

（1）产品定位：

我是一个什么样的产品
什么背景基因下产生
为哪些目标市场服务
服务的边界是什么

（2）产品定义：

定义用户：
- 选择哪类用户作为目标用户
- 目标用户画像之User Persona特征
定义场景：
- 用户场景：问题、想法、发现解决方案
- 使用场景：使用
- 营销场景：看到、选择、购买
定义价值
- 用户价值
- 商业价值
- 用户价值与商业价值的平衡
全局思考：
- 产品的持续性
- 产品的增长性

（3）战略规划：

组织架构从上到下的战略传递
产品组合策略
产品路线图

（4）产品设计：

基于场景和需求拆分用户的任务
基于任务拆分为功能和交互、内容和信息架构
基于全局考虑业务闭环、产品结构的可拓展性

（5）产品研发：

界面设计（设备、交互、UI等）
技术研发
可用性测试及用户体验测试等
持续迭代

（6）产品运营

上线前基于产品的运营计划

（7）分析产出

用户画像之User Persona
用户旅程图
产品阶段战略
产品路线图
应用架构图
产品功能框架图
界面对比结论

~~ ~

3.4、从市场角度看产品

在新产品推向市场后的销售营销、运营、根据需求演变的产品迭代，也要经过进入期、成长期、成熟期和衰退期是个阶段。

在不同的产品生命周期阶段，企业经营行为的侧重点不同。

（1）产品商业模式

（2）产品/市场匹配（PMF）

PMF是Product Market Fit的简写，是指产品和市场达到最佳的契合点。象征着产品正好满足市场的需求，令客户满意，这是产品成功的第一步。

PMF的实现标准（临界点）的判断，各行各业因其特性均不同，网上有些判断方法仅供参考：

财务状况增长率+利润率大于40%
次日留存大于30%
每周使用天数超过3天
付费转化率大于5%
LTV／CAC>3
用户月流失低于5%
用户获取成本的回本时间少于12个月
不能再使用该产品会感觉非常失望的用户量占比大于40%（调研分四挡：非常失望、有点失望、没有失望和不适用）

（3）产品功能：

主要功能
次要功能
附加功能

（4）所用技术：

技术类型
技术架构
技术水平

（5）运营推广：

内容运营
- 企业介绍
- 企业新闻
  - 融资信息
  - 客户签约信息
  - 战略合作信息
  - 产品动态信息
- 产品手册
- 客户成功案例
- 行业白皮书
- 行业解决方案
- 行业报告、干货资料
  - 行业热点分析
  - 行业趋势解读
- 期刊、书籍等出版物
- 电子书
- 课程讲义
  - 老板专栏/高管专栏/大咖专栏
  - 特定选题的课程
活动运营
- 线上
  - 微课
  - 直播
- 线下
  - 主办型活动
  - 联合型活动
  - 赞助型活动
  - 企业参访活动
  - 会销活动
  - 培训活动、沙龙活动
  - 游学活动
  - 线下公开课
渠道运营
- 官网媒体
- 自媒体：公众号、头条、搜狐号等等
- 全员营销
- 联合推广渠道
  - 自媒体大号联盟
  - 行业俱乐部及协会
  - 行业媒体、杂志体
- 贡献线索渠道
  - 广告渠道、SEM
  - 垂直行业网站
  - 同客异业合作
  - 产业上下游企业合作
- 代理商渠道
  - 渠道加盟商
  - 交易平台，如用友云市场
社群运营
运营体系及风格
运营事件分析，关注和研究显著的增长点
关注各类运营数据及转化率

（6）销售/营销

定价策略
市场营销
销售模式
- 直销
- 代销
- 经销
- 网络销售
- 电话销售
销售渠道及渠道策略
品牌管理

关于定价方法，UCPM的总结比较全面到位，这里罗列一下，百度即可。重在比较不同竞争者的定价策略。

~~~

3.5、从产品角度看用户

当产品中沉淀了一些存量用户之后，为了实现用户需求的异质性、并集中有限资源进行有效市场竞争的行为。企业在明确的战略业务模式和特定的市场中，根据用户的属性，行为等因素对用户进行分类，并提供有针对性的产品、服务、销售、运营模式，达到用户价值和产品目标的最大化。

系统实施层面，是在抽象理论的指导下，用算法进行标签化统计、分类，并以用户画像的形式表现，最后在策略上、界面上、运营方式上进行“量体裁衣”。

（1）分析对象：产品中现有的用户

（2）分析目的：对用户细分，精细化运营，不同用户采用不同的运营策略

（3）分析内容：

用户画像之User Profile
标签分析、标签标注
用户相关方利益分析
不同用户消费特点
用户习惯
用户同理心分析
用户行为旅程
用户体验

越来越多的产品也逐渐从更多细致的维度来分析消费者，对2C用户的分析维度分为以下五类：

对2B企业的分析维度，大致分为以下三类：

（4）分析方法：

定性：人种学现场调查、眼动跟踪、可用性实验室研究、用户反馈分析
定量：埋点数据分析、A/B测试、用户体验调查问卷

~~~

3.6、从用户角度看产品

我们通常需要以不同的角色来体验和感受产品，而且能在各个角色之间切换自如。角色可以分以下几类：

用户、商家、广告商
小白用户、普通用户、专家用户
决策者、购买者、使用者、影响者、信息管理者
界面设计面向的主要人物、次要人物、补充人物、客户人物、接受服务人物、负面人物

（1）产品覆盖的场景有哪些？能满足哪些需求？能给我带来什么价值？

（2）多端比较：

Android
IOS
WP

（3）多商业入口分析：

APP
H5
PC
公众号
小程序

（4）功能：

主要功能
次要功能
附加功能

（5）UI与交互

主要功能入口是否清晰明确？
各入口间跳转是否会迷失？
最重要的页面有没有直接展示？

（6）其他

安全性
性能：是否稳定，不卡顿，响应速度
获得性：客户能否方便的获得服务
易用性：操作便利性、学习的难易程度
后续服务：不断升级，维护报修服务的便利性
用户评价

~~~

3.7、从产品背后看企业

企业本质上是“一种资源配置的机制”，其能够实现整个社会经济资源的优化配置，降低整个社会的“交易成本”。从产品背后看企业，才能看到产品的基因与营养。

（1）分析对象：产品所属的企业

（2）分析目的：分析竞品所属企业的资源配置机制

（3）分析方法：

定性：历史追踪法、主观体验与评价
定量：特征罗列、要素列举

（4）分析领域：

企业背景
企业历程及重大节点
企业定位
企业愿景
发展战略
- 进攻
- 防御
- 横向扩张
业务模式
- 上游
- 下游
产品矩阵
- 波士顿产品矩阵
- 产品组合策略
产品战略
- 组织架构从上到下的战略传递
- 产品路线图
商业模式（商业画布）
人力资源：
- 创始人概括
- 核心骨干人员优势
- 团队背景
- 组织架构
- 人员数量
财务资源：
- 投融资情况
- 盈利能力
- 运营投入
实物资源：工厂车间、机器设备、工具器具、生产资料、土地、房屋等具有物质形态的固定资产
技术资源：
- 技术专利
- 影响用户体验的技术
- 市场发展的技术
社会资源：
- 政府关系
- 合作伙伴
- 社会名人
- 重要事件
其他资源：时空资源、信息资源、品牌资源、文化资源、管理资源

四、 4类信息来源

4.1、来自分析者自身的信息

（1）成为用户

（2）体验产品

（3）轮岗实习

4.2、来自用户的信息

（1）用户调研

（2）用户反馈

（3）用户数据分析

4.3、来自竞争者的信息

（1）公司官网

财务报表
融资情况
活动线索：产品发布会、行业峰会，展览会，推广活动
媒体线索：官网、微博、公众号、媒体报道、高管访谈、产品的运营事件和运营信

（2）产品使用：产品体验、产品文档

（3）竞争者的员工

客服人员：作为消费者给竞品客服打电话咨询问题
离职人员：在合法范围内做咨询

（4）互动交流

4.4、来自第三方的信息

（1）政府机构：查看政府的工作统计报告

（2）行业研究机构：行业报告、案例研究和论文，能了解行业现状和市场格局。

（3）第三方调研机构

（4）专利机构：可检索竞品涉及的专利

（5）合作伙伴：从合作伙伴处了解竞品

（6）应用商店的数据统计平台：查看产品排名、用户评价、下载量统计、活跃用户规模、版本迭代记录等

五、 3个信息处理步骤

5.1、信息收集

（1）编写

（2）爬取

（3）问卷、访谈

（4）数据库调取

（5）购买

5.2、信息清洗

（1）重复信息：

合并
删除重复项

（2）残缺信息：

补全。补全缺失的信息
估算。用样本统计的估算值代替缺失信息
推导。用样本模型计算出来的值代替缺失信息
忽略。忽略掉与分析目标相关度小的信息
遗留。做缺失记录，暂时不做处理。

（3）错误信息

更正
删除

（4）不一致信息

相互关联
相互统一

5.3、信息加工

将清洗过的信息加工成我们想要的信息

提取。从多段信息中提取某个专题需要的信息
计算。利用已有数据按公式计算出另一数据
分组。合理分组，合并同类项，排列组合
转化。信息类型间的转化，格式统一

5.4、信息 抽样

个别信息，尤其数据类的信息，需要抽样检查

5.5、信息更新

市场变化快，信息须及时更新

六、 6类分析方法

6.1、主观与客观

（1）主观：体验、描述、评价

（2）客观：特征罗列、流程呈现、要素列举、公式计算

6.2、定性与定量

6.3、理论模型

有一些现成的理论模型是可以直接套用的，列举如下：

PEST
STP理论
波特五力模型
波士顿矩阵分析
用户体验五要素
$APPEALS
SWOT

6.4、分析方法

（1）对比分析法：最简单的对比是罗列要素，进行Yes/No的打钩。

同一时空，同样条件下，不同指标的比较
同样条件，同样指标，在不同时空的比较

（2）综合评价分析（权重评分法）

专家访谈法
德尔菲法

（3）结构分析法

漏斗分析
杜邦分析

（4）四象限法（矩阵分析法）。一般选择两个关键竞争要素，通过四象限来分析竞品之间关键指标的分布情况。如波士顿矩阵法也属于四象限法。

（5）历史跟踪法。

迭代版本的追踪
运营手法的追踪

七、 报告模板

~完~

参考资料：海比研究院《2021年中国SaaS市场研究报告》、艾瑞咨询部分行业报告、《UCPM产品管理知识体系》、《ToB运营-低成本获客与续费》、《产品经理装备书》、《交互设计精髓4》。

感想：

以前最爱李白诗词的浪漫狂发和神奇瑰丽，近期写文章，越发喜欢白居易诗词的通俗写实和浅显易懂，将最常见的道理用最朴素的语言书写，平头老百姓也能读懂。一个像乔布斯，一个像雷布斯，两个诗人都有很强的用户思维。

很多道理和方法是朴素实用的，可我们经常从其他地方寻找更好的，甚至更奇特的观点更喜欢去接受和探究，而更简单的需要长期坚持的东西都容易搁浅。当我反求诸己，将做任何事情的切身感受溶于产品工作时，很多事情倒是容易起来了。

何为多标签分类？这里有几种实用的经典方法

Tue, 12 Oct 2021 15:01:57 CST

众所周知，二分类任务旨在将给定的输入分为 0 和 1 两类。而多标签分类（又称多目标分类）一次性地根据给定输入预测多个二分类目标。例如，模型可以预测给定的图片是一条狗还是一只猫，同时预测其毛皮是长还是短。

在多分类任务中，预测目标是互斥的，这意味着一个输入可以对应于多个分类。本文将介绍一些可能提升多标签分类模型性能的小技巧。

模型评估函数

通过在「每一列」（分类标签）上计算模型评估函数并取得分均值，我们可以将大多数二分类评估函数用于多标签分类任务。对数损失或二分类交叉熵就是其中一种评估函数。为了更好地考虑到类别不均衡现象，我们可以使用 ROC-AUC 作为评估函数。

图 1：ROC-AUC 曲线

建模技巧

在介绍构建特征的技巧之前，本文将介绍一些设计适用于多标签分类场景的模型的小技巧。

对于大多数非神经网络模型而言，我们唯一的选择是为每个目标训练一个分类器，然后将预测结果融合起来。为此，「scikit-learn」程序库提供了一个简单的封装类「OneVsRestClassifier」。尽管这个封装类可以使分类器能够执行多标签任务，但我们不应采用这种方法，其弊端如下：（1）我们会为每个目标训练一个新模型，因此训练时间相对较长。（2）模型无法学习不同标签之间的关系或标签的相关性。

第二个问题可以通过执行一个两阶段训练过程来解决。其中，我们将目标的预测结果和原始特征相结合，作为第二阶段训练的输入。这样做的缺点是，由于需要训练的模型数量是之前的两倍，训练时间将大幅度提升。神经网络（NN）则适用于这种场景，其中标签的数量即为网络中输出神经元的数量。我们可以直接将任意的二分类损失应用于神经网络模型，同时该模型会输出所有的目标。此时，我们只需要训练一个模型，且网络可以通过输出神经元学习不同标签的相关性，从而解决上文中提出的非神经网络模型的两个问题。

图 2：神经网络

有监督的特征选择方法

在开始特征工程或特征选择之前，需要对特征进行归一化和标准化处理。使用「scikit-learn」库中的「Quantile Transformer」将减小数据的偏度，使特征服从正态分布。此外，还可以通过对数据采取「减去均值，除以标准差」的操作，对特征进行标准化处理。该过程与「Quantile Transformer」完成了类似的工作，其目的都是对数据进行变换，使数据变得更加鲁棒。然而，「Quantile Transformer」的计算开销较高。

大多数算法都是为单一目标设计的，因此使用有监督特征选择方法稍微有些困难。为了解决这个问题，我们可以将多标签分类任务转化为多类分类问题。「Label Powerset」就是其中一种流行的解决方案，它将训练数据中的每一个独特的标签组合转化为一个类。「scikit-multilearn」程序库中包含实现该方案的工具。

图 3：Label Powerset 方法

在完成转换后，我们可以使用「信息增益」和「卡方」等方法来挑选特征。尽管这种方法是可行的，但是却很难处理上百甚至上千对不同的独特标签组合。此时，使用无监督特征选择方法可能更合适。

无监督特征选择方法

在无监督方法中，我们不需要考虑多标签任务的特性，这是因为无标签方法并不依赖于标签。典型的无监督特征选择方法包括：

主成分分析（PCA）或其它的因子分析方法。此类方法会去除掉特征中的冗余信息，并为模型抽取出有用的特征。请确保在使用 PCA 之前对数据进行标准化处理，从而使每个特征对分析的贡献相等。另一个使用 PCA 的技巧是，我们可以将该算法简化后的数据作为模型可选择使用的额外信息与原始数据连接起来，而不是直接使用简化后的数据。
方差阈值。这是一种简单有效的降低特征维度的方法。我们丢弃具有低方差或离散型的特征。可以通过找到一个更好的选择阈值对此进行优化，0.5 是一个不错的初始阈值。
聚类。通过根据输入数据创建聚类簇来构建新特征，然后将相应的聚类分配给每一行输入数据，作为一列新的特征。

图 4：K - 均值聚类

上采样方法

当分类数据高度不均衡时，可以使用上采样方法为稀有类生成人造样本，从而让模型关注稀有类。为了在多标签场景下创建新样本，我们可以使用多标签合成少数类过采样技术（MLSMOTE）。

代码链接：https://github.com/niteshsukhwani/MLSMOTE

该方法由原始的 SMOTE 方法修改而来。在生成少数类的数据并分配少数标签后，我们还通过统计每个标签在相邻数据点中出现的次数来生成其它相关的标签，并保留出现频次高于一半统计的数据点的标签。

原文链接：https://andy-wang.medium.com/bags-of-tricks-for-multi-label-classification-dc54b87f79ec

SparkSql系列(7/25) 去重方法

Tue, 24 Aug 2021 23:02:07 CST

消除重复的数据可以通过使用 distinct 和 dropDuplicates 两个方法，二者的区别在于， distinct 是所有的列进行去重的操作，假如你的 DataFrame里面有10列，那么只有这10列完全相同才会去重， dropDuplicates 则是可以指定列进行去重，相当于是 distinct 的缩小版

构建 DataFrame

import spark.implicits._

val simpleData = Seq(("James", "Sales", 3000),
  ("Michael", "Sales", 4600),
  ("Robert", "Sales", 4100),
  ("Maria", "Finance", 3000),
  ("James", "Sales", 3000),
  ("Scott", "Finance", 3300),
  ("Jen", "Finance", 3900),
  ("Jeff", "Marketing", 3000),
  ("Kumar", "Marketing", 2000),
  ("Saif", "Sales", 4100)
)
val df = simpleData.toDF("employee_name", "department", "salary")
df.show()

输出如下所示：

+-------------+----------+------+
|employee_name|department|salary|
+-------------+----------+------+
|        James|     Sales|  3000|
|      Michael|     Sales|  4600|
|       Robert|     Sales|  4100|
|        Maria|   Finance|  3000|
|        James|     Sales|  3000|
|        Scott|   Finance|  3300|
|          Jen|   Finance|  3900|
|         Jeff| Marketing|  3000|
|        Kumar| Marketing|  2000|
|         Saif|     Sales|  4100|
+-------------+----------+------+

1. 使用 distinct 去重

//Distinct all columns
val distinctDF = df.distinct()
println("Distinct count: "+distinctDF.count())
distinctDF.show(false)

distinct() 函数会返回一个新的 DataFrame ，而不是原地修改。

Distinct count: 9
+-------------+----------+------+
|employee_name|department|salary|
+-------------+----------+------+
|James        |Sales     |3000  |
|Michael      |Sales     |4600  |
|Maria        |Finance   |3000  |
|Robert       |Sales     |4100  |
|Saif         |Sales     |4100  |
|Scott        |Finance   |3300  |
|Jeff         |Marketing |3000  |
|Jen          |Finance   |3900  |
|Kumar        |Marketing |2000  |
+-------------+----------+------+

或者你不指定 dropDuplicates 的参数，也是可以达到上面的效果

val df2 = df.dropDuplicates()
println("Distinct count: "+df2.count())
df2.show(false)

2. 使用 dropDuplicates 按照指定列进行去重

与 distinct 一样，函数都会返回一个新的 DataFrame

//Distinct using dropDuplicates
val dropDisDF = df.dropDuplicates("department","salary")
println("Distinct count of department & salary : "+dropDisDF.count())
dropDisDF.show(false)

结果如下所示：

Distinct count of department & salary : 8
+-------------+----------+------+
|employee_name|department|salary|
+-------------+----------+------+
|Jen          |Finance   |3900  |
|Maria        |Finance   |3000  |
|Scott        |Finance   |3300  |
|Michael      |Sales     |4600  |
|Kumar        |Marketing |2000  |
|Robert       |Sales     |4100  |
|James        |Sales     |3000  |
|Jeff         |Marketing |3000  |
+-------------+----------+------+

3. 完整的示例代码

import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._

object SQLDistinct extends App {

  val spark: SparkSession = SparkSession.builder()
    .master("local[1]")
    .appName("SparkByExamples.com")
    .getOrCreate()

  spark.sparkContext.setLogLevel("ERROR")

  import spark.implicits._

  val simpleData = Seq(("James", "Sales", 3000),
    ("Michael", "Sales", 4600),
    ("Robert", "Sales", 4100),
    ("Maria", "Finance", 3000),
    ("James", "Sales", 3000),
    ("Scott", "Finance", 3300),
    ("Jen", "Finance", 3900),
    ("Jeff", "Marketing", 3000),
    ("Kumar", "Marketing", 2000),
    ("Saif", "Sales", 4100)
  )
  val df = simpleData.toDF("employee_name", "department", "salary")
  df.show()

  //Distinct all columns
  val distinctDF = df.distinct()
  println("Distinct count: "+distinctDF.count())
  distinctDF.show(false)

  val df2 = df.dropDuplicates()
  println("Distinct count: "+df2.count())
  df2.show(false)

  //Distinct using dropDuplicates
  val dropDisDF = df.dropDuplicates("department","salary")
  println("Distinct count of department & salary : "+dropDisDF.count())
  dropDisDF.show(false)

}

RSA加密、解密、签名、验签的原理及方法 - PC君 - 博客园

Sun, 18 Jul 2021 10:12:30 CST

一、RSA加密简介

　　RSA加密是一种非对称加密。可以在不直接传递密钥的情况下，完成解密。这能够确保信息的安全性，避免了直接传递密钥所造成的被破解的风险。是由一对密钥来进行加解密的过程，分别称为公钥和私钥。两者之间有数学相关，该加密算法的原理就是对一极大整数做因数分解的困难性来保证安全性。通常个人保存私钥，公钥是公开的（可能同时多人持有）。

二、RSA加密、签名区别

　　加密和签名都是为了安全性考虑，但略有不同。常有人问加密和签名是用私钥还是公钥？其实都是对加密和签名的作用有所混淆。简单的说，加密是为了防止信息被泄露，而签名是为了防止信息被篡改。这里举2个例子说明。

第一个场景：战场上，B要给A传递一条消息，内容为某一指令。

RSA的加密过程如下：

（1）A生成一对密钥（公钥和私钥），私钥不公开，A自己保留。公钥为公开的，任何人可以获取。

（2）A传递自己的公钥给B，B用A的公钥对消息进行加密。

（3）A接收到B加密的消息，利用A自己的私钥对消息进行解密。

　　在这个过程中，只有2次传递过程，第一次是A传递公钥给B，第二次是B传递加密消息给A，即使都被敌方截获，也没有危险性，因为只有A的私钥才能对消息进行解密，防止了消息内容的泄露。

第二个场景：A收到B发的消息后，需要进行回复“收到”。

RSA签名的过程如下：

（1）A生成一对密钥（公钥和私钥），私钥不公开，A自己保留。公钥为公开的，任何人可以获取。

（2）A用自己的私钥对消息加签，形成签名，并将加签的消息和消息本身一起传递给B。

（3）B收到消息后，在获取A的公钥进行验签，如果验签出来的内容与消息本身一致，证明消息是A回复的。

　　在这个过程中，只有2次传递过程，第一次是A传递加签的消息和消息本身给B，第二次是B获取A的公钥，即使都被敌方截获，也没有危险性，因为只有A的私钥才能对消息进行签名，即使知道了消息内容，也无法伪造带签名的回复给B，防止了消息内容的篡改。

　　但是，综合两个场景你会发现，第一个场景虽然被截获的消息没有泄露，但是可以利用截获的公钥，将假指令进行加密，然后传递给A。第二个场景虽然截获的消息不能被篡改，但是消息的内容可以利用公钥验签来获得，并不能防止泄露。所以在实际应用中，要根据情况使用，也可以同时使用加密和签名，比如A和B都有一套自己的公钥和私钥，当A要给B发送消息时，先用B的公钥对消息加密，再对加密的消息使用A的私钥加签名，达到既不泄露也不被篡改，更能保证消息的安全性。

　　 总结：公钥加密、私钥解密、私钥签名、公钥验签。

三、RSA加密、签名的方法，代码例子如下：

  1 import java.io.ByteArrayOutputStream;
  2 import java.security.KeyFactory;
  3 import java.security.KeyPair;
  4 import java.security.KeyPairGenerator;
  5 import java.security.PrivateKey;
  6 import java.security.PublicKey;
  7 import java.security.Signature;
  8 import java.security.spec.PKCS8EncodedKeySpec;
  9 import java.security.spec.X509EncodedKeySpec;
 10 import javax.crypto.Cipher;
 11 import org.apache.commons.codec.binary.Base64;
 12 
 13 public class TestRSA {
 14 
 15     /**
 16      * RSA最大加密明文大小
 17      */
 18     private static final int MAX_ENCRYPT_BLOCK = 117;
 19 
 20     /**
 21      * RSA最大解密密文大小
 22      */
 23     private static final int MAX_DECRYPT_BLOCK = 128;
 24 
 25     /**
 26      * 获取密钥对
 27      * 
 28      * @return 密钥对
 29      */
 30     public static KeyPair getKeyPair() throws Exception {
 31         KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA");
 32         generator.initialize(1024);
 33         return generator.generateKeyPair();
 34     }
 35 
 36     /**
 37      * 获取私钥
 38      * 
 39      * @param privateKey 私钥字符串
 40      * @return
 41      */
 42     public static PrivateKey getPrivateKey(String privateKey) throws Exception {
 43         KeyFactory keyFactory = KeyFactory.getInstance("RSA");
 44         byte[] decodedKey = Base64.decodeBase64(privateKey.getBytes());
 45         PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(decodedKey);
 46         return keyFactory.generatePrivate(keySpec);
 47     }
 48 
 49     /**
 50      * 获取公钥
 51      * 
 52      * @param publicKey 公钥字符串
 53      * @return
 54      */
 55     public static PublicKey getPublicKey(String publicKey) throws Exception {
 56         KeyFactory keyFactory = KeyFactory.getInstance("RSA");
 57         byte[] decodedKey = Base64.decodeBase64(publicKey.getBytes());
 58         X509EncodedKeySpec keySpec = new X509EncodedKeySpec(decodedKey);
 59         return keyFactory.generatePublic(keySpec);
 60     }
 61     
 62     /**
 63      * RSA加密
 64      * 
 65      * @param data 待加密数据
 66      * @param publicKey 公钥
 67      * @return
 68      */
 69     public static String encrypt(String data, PublicKey publicKey) throws Exception {
 70         Cipher cipher = Cipher.getInstance("RSA");
 71         cipher.init(Cipher.ENCRYPT_MODE, publicKey);
 72         int inputLen = data.getBytes().length;
 73         ByteArrayOutputStream out = new ByteArrayOutputStream();
 74         int offset = 0;
 75         byte[] cache;
 76         int i = 0;
 77         // 对数据分段加密
 78         while (inputLen - offset > 0) {
 79             if (inputLen - offset > MAX_ENCRYPT_BLOCK) {
 80                 cache = cipher.doFinal(data.getBytes(), offset, MAX_ENCRYPT_BLOCK);
 81             } else {
 82                 cache = cipher.doFinal(data.getBytes(), offset, inputLen - offset);
 83             }
 84             out.write(cache, 0, cache.length);
 85             i++;
 86             offset = i * MAX_ENCRYPT_BLOCK;
 87         }
 88         byte[] encryptedData = out.toByteArray();
 89         out.close();
 90         // 获取加密内容使用base64进行编码,并以UTF-8为标准转化成字符串
 91         // 加密后的字符串
 92         return new String(Base64.encodeBase64String(encryptedData));
 93     }
 94 
 95     /**
 96      * RSA解密
 97      * 
 98      * @param data 待解密数据
 99      * @param privateKey 私钥
100      * @return
101      */
102     public static String decrypt(String data, PrivateKey privateKey) throws Exception {
103         Cipher cipher = Cipher.getInstance("RSA");
104         cipher.init(Cipher.DECRYPT_MODE, privateKey);
105         byte[] dataBytes = Base64.decodeBase64(data);
106         int inputLen = dataBytes.length;
107         ByteArrayOutputStream out = new ByteArrayOutputStream();
108         int offset = 0;
109         byte[] cache;
110         int i = 0;
111         // 对数据分段解密
112         while (inputLen - offset > 0) {
113             if (inputLen - offset > MAX_DECRYPT_BLOCK) {
114                 cache = cipher.doFinal(dataBytes, offset, MAX_DECRYPT_BLOCK);
115             } else {
116                 cache = cipher.doFinal(dataBytes, offset, inputLen - offset);
117             }
118             out.write(cache, 0, cache.length);
119             i++;
120             offset = i * MAX_DECRYPT_BLOCK;
121         }
122         byte[] decryptedData = out.toByteArray();
123         out.close();
124         // 解密后的内容 
125         return new String(decryptedData, "UTF-8");
126     }
127 
128     /**
129      * 签名
130      * 
131      * @param data 待签名数据
132      * @param privateKey 私钥
133      * @return 签名
134      */
135     public static String sign(String data, PrivateKey privateKey) throws Exception {
136         byte[] keyBytes = privateKey.getEncoded();
137         PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(keyBytes);
138         KeyFactory keyFactory = KeyFactory.getInstance("RSA");
139         PrivateKey key = keyFactory.generatePrivate(keySpec);
140         Signature signature = Signature.getInstance("MD5withRSA");
141         signature.initSign(key);
142         signature.update(data.getBytes());
143         return new String(Base64.encodeBase64(signature.sign()));
144     }
145 
146     /**
147      * 验签
148      * 
149      * @param srcData 原始字符串
150      * @param publicKey 公钥
151      * @param sign 签名
152      * @return 是否验签通过
153      */
154     public static boolean verify(String srcData, PublicKey publicKey, String sign) throws Exception {
155         byte[] keyBytes = publicKey.getEncoded();
156         X509EncodedKeySpec keySpec = new X509EncodedKeySpec(keyBytes);
157         KeyFactory keyFactory = KeyFactory.getInstance("RSA");
158         PublicKey key = keyFactory.generatePublic(keySpec);
159         Signature signature = Signature.getInstance("MD5withRSA");
160         signature.initVerify(key);
161         signature.update(srcData.getBytes());
162         return signature.verify(Base64.decodeBase64(sign.getBytes()));
163     }
164 
165     public static void main(String[] args) {
166         try {
167             // 生成密钥对
168             KeyPair keyPair = getKeyPair();
169             String privateKey = new String(Base64.encodeBase64(keyPair.getPrivate().getEncoded()));
170             String publicKey = new String(Base64.encodeBase64(keyPair.getPublic().getEncoded()));
171             System.out.println("私钥:" + privateKey);
172             System.out.println("公钥:" + publicKey);
173             // RSA加密
174             String data = "待加密的文字内容";
175             String encryptData = encrypt(data, getPublicKey(publicKey));
176             System.out.println("加密后内容:" + encryptData);
177             // RSA解密
178             String decryptData = decrypt(encryptData, getPrivateKey(privateKey));
179             System.out.println("解密后内容:" + decryptData);
180             
181             // RSA签名
182             String sign = sign(data, getPrivateKey(privateKey));
183             // RSA验签
184             boolean result = verify(data, getPublicKey(publicKey), sign);
185             System.out.print("验签结果:" + result);
186         } catch (Exception e) {
187             e.printStackTrace();
188             System.out.print("加解密异常");
189         }
190     }
191 }

　　PS:RSA加密对明文的长度有所限制，规定需加密的明文最大长度=密钥长度-11（单位是字节，即byte），所以在 加密和解密的过程中需要分块进行。而密钥默认是1024位，即1024位/8位-11=128-11=117字节。所以默认加密前的明文最大长度117字节，解密密文最大长度为128字。那么为啥两者相差11字节呢？是因为RSA加密使用到了填充模式（padding），即内容不足117字节时会自动填满，用到填充模式自然会占用一定的字节，而且这部分字节也是参与加密的。

　　密钥长度的设置就是上面例子的第32行。可自行调整，当然非对称加密随着密钥变长，安全性上升的同时性能也会有所下降。

oracle 索引失效原因及解决方法 - chenxiangxiang - 博客园

Wed, 14 Jul 2021 07:49:49 CST

oracle 索引失效原因及解决方法

2010年11月26日星期五 17:10

一、以下的方法会引起索引失效

‍1,<>
2,单独的>,<,(有时会用到，有时不会)
3,like "%_" 百分号在前.
4,表没分析.
5,单独引用复合索引里非第一位置的索引列.
6,字符型字段为数字时在where条件里不添加引号.
7,对索引列进行运算.需要建立函数索引.
8,not in ,not exist.
9,当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。
10, 索引失效。
11,基于cost成本分析(oracle因为走全表成本会更小)：查询小表,或者返回值大概在10%以上
12,有时都考虑到了但就是不走索引,drop了从建试试在
13,B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走
14,联合索引 is not null 只要在建立的索引列（不分先后）都会走,
in null时必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,其他建立索引的列可以是is null（但必须在所有列都满足is null的时候）,或者=一个值；
当建立索引的第一位置是=一个值时,其他索引列可以是任何情况（包括is null =一个值）,以上两种情况索引都会走。其他情况不会走。

二、索引失效解决方法

1. 选用适合的Oracle优化器

Oracle的优化器共有3种:

a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性)。

设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。你当然也在SQL句级或是会话(session)级对其进行覆盖。

为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行analyze 命令,以增加数据库中的对象统计信息(object statistics)的准确性。

如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关。如果table已经被analyze过, 优化器模式将自动成为CBO , 反之,数据库将采用RULE形式的优化器。

（分析table

analyze table PROD_PARTS compute statistics;

ANALYZE TABLE PROD_PARTS COMPUTE STATISTICS FOR ALL INDEXED COLUMNS;

analyze table PROD_PARTS compute statistics for table for all indexes for all indexed columns;

）【有一次索引失效之后，请教DBA后，发现是数据统计的问题，具体的解决办法是执行以上语句】

在缺省情况下,Oracle采用CHOOSE优化器, 为了避免那些不必要的全表扫描（full table scan）, 你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器。

2、‍重建索引
‍alter index 索引名 rebuild 【online】

3、强制索引

给该语句加上hint后，强制其使用'RECORD_ENTITYID' 这个索引

sql语句变成这样

引用

select /*+ index(record,record_entityid) */ *

from RECORD

where entityId='24' and entityType='blog';

/*+ index(record,record_entityid) */ 中，index表示强制使用index，record是表名，record_entityid是索引名。其执行计划跟测试数据库上一致，都是使用用 'RECORD_ENTITYID' 这个索引，逻辑读写同样为4。

后来经过测试，在不加hint的情况下，对该表和两个索引执行analyze 后，同样也能使用 'RECORD_ENTITYID' 这个索引。但是因为该表更新颇为频繁，不知道要多久就要再分析一次

转载自： http://hi.baidu.com/%CC%EC%C0%B6%D2%ED%D0%C4/blog/item/126f0458aa458691810a189d.html

但是如果是同样的sql如果在之前能够使用到索引，那么现在使用不到索引，以下几种主要情况:索引失效的原因

1. 随着表的增长，where条件出来的数据太多，大于15%，使得索引失效（会导致CBO计算走索引花费大于走全表）

2. 统计信息失效需要重新搜集统计信息

3. 索引本身失效需要重建索引

下面是一些不会使用到索引的原因

索引失效

1) 没有查询条件，或者查询条件没有建立索引

2) 在查询条件上没有使用引导列

3) 查询的数量是大表的大部分，应该是30％以上。

4) 索引本身失效

5) 查询条件使用函数在索引列上（见12）

6) 对小表查询

7) 提示不使用索引

8) 统计数据不真实

9) CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小。

10)隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误. 由于表的字段tu_mdn定义为varchar2(20),

但在查询时把该字段作为number类型以where条件传给 Oracle,这样会导致索引失效.

错误的例子：select * from test where tu_mdn=13333333333;

正确的例子：select * from test where tu_mdn='13333333333';

11)对索引列进行运算导致索引失效,我所指的对索引列进行运算包括(+，-，*，/，! 等)

错误的例子：select * from test where id-1=9;

正确的例子：select * from test where id=10;

12)使用Oracle内部函数导致索引失效.对于这样情况应当创建基于函数的索引.

错误的例子：select * from test where round(id)=10;

说明，此时id的索引已经不起作用了正确的例子：首先建立函数索引，

create index test_id_fbi_idx on test(round(id));

然后 select * from test where round(id)=10; 这时函数索引起作用了 1,<> 2,单独的>,<,(有时会用到，有时不会)

3,like "%_" 百分号在前.

4,表没分析.

5,单独引用复合索引里非第一位置的索引列.

6,字符型字段为数字时在where条件里不添加引号.

7,对索引列进行运算.需要建立函数索引.

8,not in ,not exist.

9,当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。

10, 索引失效。

11,基于cost成本分析(oracle因为走全表成本会更小)：查询小表,或者返回值大概在10%以上

12,有时都考虑到了但就是不走索引,drop了从建试试在

13,B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走

14,联合索引 is not null 只要在建立的索引列（不分先后）都会走,

in null时必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,

其他建立索引的列可以是is null（但必须在所有列都满足is null的时候）,

或者=一个值；当建立索引的第一位置是=一个值时,其他索引列可以是任何情况（包括is null =一个值）,

以上两种情况索引都会走。其他情况不会走。

MySQL大表数据归档的几种方法介绍 - 简书

Sat, 03 Jul 2021 11:41:43 CST

使用MySQL的过程，经常会遇到一个问题，比如说某张”log”表，用于保存某种记录，随着时间的不断的累积数据，但是只有最新的一段时间的数据是有用的；这个时候会遇到性能和容量的瓶颈，需要将表中的历史数据进行归档。下面来说说几种常见的数据归档方式。

一、使用分区，再利用分区交换技术能够很好地把指定分区中的数据移动到指定表中，这个需要在项目之处就进行此操作。

二、利用存储过程和事件来定期进行数据的导出删除操作。

1 、创建一个新表，表结构和索引与旧表一模一样

create table table_new like table_old;

2 、新建存储过程，查询30天的数据并归档进新数据库，然后把30天前的旧数据从旧表里删除

delimiter $

create procedure sp()

begin

insert into tb_new select * from table_old where rectime < NOW() - INTERVAL 30 DAY;

delete from db_smc.table_old where rectime < NOW() - INTERVAL 30 DAY;

end

3、创建EVENT，每天晚上凌晨00：00定时执行上面的存储过程

create event if not exists event_temp

on schedule every 1 day

on completion preserve

do call sp();

备注：第一次执行存储过程的时候因为历史数据过大, 可能发生意外让该次执行没有成功。重新执行时会遇到报错ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，应急解决方案如下：

1、执行show full processlist;查看所有MySQL线程。

2、执行SELECT * FROM information_schema.INNODB_TRX\G; 查看是否有错误线程，线程id在show full processlist;的结果中状态为sleep。

3、kill进程id。

另外写存储过程的时候可以控制事务的大小，比如说可以根据时间字段每次归档一天或者更小时间段的数据，这样就不会有大事务的问题，里面还可以加入日志表，每次归档操作的行为都写入日志表，以后查起来也一目了然。

三、使用percona-toolkit的pt-archiver工具来进行历史数据归档，支持删除和不删除元数据的选择。

pt-archiver使用的场景:

1、清理线上过期数据。

2、清理过期数据，并把数据归档到本地归档表中，或者远端归档服务器。

3、两张表之间的数据不完全相同，希望合并。此时加上–ignore或–replace选项，可以轻松实现。

4、导出线上数据，到线下数据作处理。

其它作用：

1、用于清理过期数据purge

$ pt-archiver --source h=10.99.73.9,P=3306,u=mha,p=123456,D=sbtest,t=sbtest \

--no-check-charset \

--where 'id<50000' \

--purge \

--limit=2 \

--statistics

注意： --source后的DSN之间不能空格出现，否则会出错。 --where条件的值，有字符串的，要用引号括起来。 --limit表示，每组一次删除多少条数据（注意：如果数据比较多时，也可以设置大一些，减少循环次数），最终的清理操作，还是通过Where pK=xx来处理的。

2、用于把数据导出文件，不用删除原表中数据

$ pt-archiver --source h=10.99.73.9,P=3306,u=mha,p=123456,D=sbtest,t=sbtest \

--dest h=10.99.73.9,P=3306,u=mha,p=123456,D=sbtest,t=sbtest_201703 \

--no-check-charset \

--where 'id>50000' \

--progress 5000 \

--no-delete \

--file "/tmp/pt-archiver.dat" \

--limit=10000 \

--txn-size=10000 \

--statistics

参数说明：

--statistics：结束的时候给出统计信息：开始的时间点，结束的时间点，查询的行数，归档的行数，删除的行数，以及各个阶段消耗的总的时间和比例，便于以此进行优化。

--where：给出表中要处理的数据的查询条件。

--progress：每处理progress指定的行数后，就打印一次信息。

--no-delete：表示不删除原来的数据，注意：如果不指定此参数，所有处理完成后，都会清理原表中的数据。

--limit：表示每次事务删除多少条数据，默认1条（注意：如果数据比较多时，也可以设置大一些，减少循环次数）。

--txn-size：每个事务提交的数据行数（包括读写操作），批量提交，增加该值可以提升归档性能。

--file：数据存放的文件，最好指定绝对路径，文件名可以灵活地组合（另外，我测试过写文件与不写文件速度几乎差不多，原本以为不写文件速度会快）。

%d Day of the month, numeric (01..31)

%H Hour (00..23)

%i Minutes, numeric (00..59)

%m Month, numeric (01..12)

%s Seconds (00..59)

%Y Year, numeric, four digits

%D Database name

%t Table name

注意字符集问题

如果你的数据库字符集是utf8的话，需要在运行pt-archive的机器上，在/etc/my.cnf文件中的[client]下面添加default-character-set = utf8，否则导出的文件内容中文会乱码，我就被这个问题坑了。

测试归档

首先压测100万数据。

mysql> create database sbtest charset utf8;

$sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-socket=/var/lib/mysql/mysql.sock --mysql-db=sbtest --db-driver=mysql --tables=1 --table-size=100000 --report-interval=10 --threads=128 --time=120 prepare

mysql> select count(1) from sbtest1;

+----------+

| count(1) |

+----------+

| 100000 |

+----------+

1 row in set (0.04 sec)

创建一张归档表，表结构跟原表一样。

mysql> show create table sbtest1\G

*************************** 1. row ***************************

       Table: sbtest

Create Table: CREATE TABLE `sbtest` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `k` int(10) unsigned NOT NULL DEFAULT '0',

  `c` char(120) NOT NULL DEFAULT '',

  `pad` char(60) NOT NULL DEFAULT '',

  PRIMARY KEY (`id`),

  KEY `k` (`k`)

) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8

1 row in set (0.00 sec)

mysql> CREATE TABLE `sbtest_2018` (

`id` int(10) unsigned NOT NULL AUTO_INCREMENT,

`k` int(10) unsigned NOT NULL DEFAULT '0',

`c` char(120) NOT NULL DEFAULT '',

`pad` char(60) NOT NULL DEFAULT '',

PRIMARY KEY (`id`),

KEY `k` (`k`)

) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8;

开始进行归档表操作，并且删除原有表数据记录（如果不删除原表数据需要加 --no-delete）

$pt-archiver --source h=localhost,u=root,D=sbtest,t=sbtest1 --dest h=localhost,u=root,D=sbtest,t=sbtest1_2018 --no-check-charset --where 'id>25000' --progress 5000 --file "/tmp/pt-archiver.dat" --limit=10000 --txn-size=10000 --statistics

TIME ELAPSED COUNT

2018-02-25T16:03:32 0 0

2018-02-25T16:03:34 2 5000

2018-02-25T16:03:37 4 10000

2018-02-25T16:03:39 6 15000

2018-02-25T16:03:41 8 20000

2018-02-25T16:03:43 10 25000

2018-02-25T16:03:43 10 25000

Started at 2018-02-25T16:03:32, ended at 2018-02-25T16:03:43

Source: D=sbtest,h=localhost,t=sbtest1,u=root

Dest: D=sbtest,h=localhost,t=sbtest1_2018,u=root

SELECT 25000

INSERT 25000

DELETE 25000

Action Count Time Pct

inserting 25000 4.1222 37.47

deleting 25000 3.7808 34.37

print_file 25000 0.1496 1.36

select 4 0.0590 0.54

commit 6 0.0397 0.36

other 0 2.8491 25.90

mysql> select count(*) from sbtest1;

+----------+

| count(*) |

+----------+

| 25001 |

+----------+

1 row in set (0.01 sec)

mysql> select count(*) from sbtest1_2018;

+----------+

| count(*) |

+----------+

| 25000 |

+----------+

1 row in set (0.01 sec)

可以看到数据已经归档完毕，并且删除数据完毕。生产环境中一般都是根据日期来归档数据，比如常见需求保留30天即可，此时where可以这么写“CreateTime <= date_add(now(), interval -30 day)”。

除了用pt-archiver归档之外，还有一个特别大的用处，我给称之为“无锁导入数据”。在数据归档中还有一种需求（我经常遇到），为了不影响业务在某些情况下会对一些日志表或者其他表做归档，当表特别大时第一次处理此表就不太好处理，并且就算把表数据删除了后而表文件还是无法缩小。这个时候就可以用MySQL的神奇rename命令对表进行重命名，当然是业务允许情况下，如 rename table Deal to Deal_201801, Deal_2018 to Deal;，此操作是一个原子操作且特别快。做完这个动作之后，一般还会有一个需求就是把原表中某一段时间的数据导入到新的表中，可能是业务跑批需要或者后台查询需要。导数据该怎么弄呢？很自然可能想到使用 insert into Deal select * from Deal_201801 where ...导入操作，但是不好意思，这个动作是锁表的，在导入数据的时候无法对新表进行操作，会导致业务异常。

如果换其他方式呢？写python或shell把数据读出来写入到文件，然后再从文件读出循环插入到新表，这当然是可以的。但当数据特别多时，也需要写多线程了。其实这个时候就可以借助pt-archiver进行数据导入了，从老的表读出来然后直接插入到新的表，他的原理与我们上面说的方式类似，但是它更友好，且更快。

四、使用union或union all来进行结果合并

当历史数据进行归档后，这个时候就有需求了。当需要查看历史数据和现有表数据时有没有什么好的方法呢？其实可以使用union或union all来进行多表结果合并操作。

在数据库中，union和union all关键字都是将两个结果集合并为一个，但这两者从使用和效率上来说都有所不同。union在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。

如：

select * from test_union1

union

select * from test_union2

这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。

而union all只是简单的将两个结果合并后就返回。这样，如果返回的两个结果集中有重复的数据，那么返回的结果集就会包含重复的数据了。从效率上说，union all要比union快很多，所以，如果可以确认合并的两个结果集中不包含重复的数据的话，那么就使用union all，如下：

select * from test_union1

union all

select * from test_union2

使用union组合查询的结果集有两个最基本的规则：

1、所有查询中的列数和列的顺序必须相同。

2、数据类型必须兼容。

虽然这个可以简便解决数据查询问题，但是还是需要代码层面的调整。

union还有一个地方可能会用到，如web项目中经常会碰到整站搜索的问题，即客户希望在网站的搜索框中输入一个词语，然后在整个网站中只要包含这个词的页面都要出现在搜索结果中。由于一个web项目不可能用一张表就全部搞定的，所以这里一般都是要用union联合搜索来解决整个问题的。

Oracle里收集与查看统计信息的方法_DBA Fighting!的技术博客_51CTO博客

Tue, 08 Jun 2021 08:51:05 CST

Oracle数据库里的统计信息是这样的一组数据：它存储在数据字典里，且从多个维度描述了Oracle数据库里对象的详细信息。CBO会利用这些统计信息来计算目标SQL各种可能的、不同的执行路径的成本，并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划。

Oracle数据库里的统计信息可以分为如下6种类型：

表的统计信息
索引的统计信息
列的统计信息
系统统计信息
数据字典统计信息
内部对象统计信息

表的统计信息用于描述Oracle数据库里表的详细信息，它包含了一些典型的维度，如记录数、表块(表里的数据块)数量、平均行长度等。

索引的统计信息于描述Oracle数据库里索引的详细信息，它包含了一些典型的维度，如索引的层级、叶子块的数量、聚簇因子等。

列的统计信息于描述Oracle数据库里列的详细信息，它包含了一些典型的维度，如列的distinct值的数量、列的NULL值的数量、列的最小值、列的最大值以及直方图等。

系统统计信息于描述Oracle数据库所在的数据库服务器的系统处理能力，它包含了CPU和I/O这两个维度，借助于系统统计信息，Oracle可以更清楚地知道目标数据库服务器的实际处理能力。

数据字典统计信息用于热核Oracle数据库里数据字典基表(如TAB$、IND$等)、数据字典基表上的索引，以及这些数据字典的列的详细信息，描述上述数据字典基表的统计信息与描述普通表、索引、列的统计信息没有本质区别。

内部对象统计信息用于描述Oracle数据库里的一些内部表(如X$系列表)的详细信息，它的维度和普通表的统计信息的维度类似，只不过其表块的数量为0，因为X$系统表实际上只是Oracle自定义的内存结构，并不占用实际的物理存储空间。

1、收集统计信息

在Oracle数据库里，通常有两种方法可以用来收集统计信息：一种是使用ANALYZE命令；另一种是使用DBMS_STATS包。表、索引、列的统计信息和数据字典统计信息用ANALYZE命令或者DBMS_STATS包收集均可，但系统统计信息和系统内部对象统计信息只能使用DBMS_STATS包来收集。

对系统内部表若使用ANALYZE命令来收集统计信息，会报错ORA-02030

1.1用ANALYZE命令收集统计信息

从Oracle7开始，ANALYZE命令就可以用来收集表、索引、列的统计信息，以及系统统计信息。

典型用法如下：

zx@ORCL>create table t2 as select * from dba_objects;

Table created.

zx@ORCL>create index idx_t2 on t2(object_id);

Index created.

zx@ORCL>analyze index idx_t2 delete statistics;

Index analyzed.

从Oracle 10g开始，创建索引后Oracle会怎么收集目标索引的统计信息，出现演示的目的，这里删除索引IDX_T2的统计信息：

执行sosi脚本，从输出内容可以看到表T2、表T2的列和索引IDX_T2均没有相关的统计信息

zx@ORCL>select count(*) from t2;

  COUNT(*)
----------
     86852

只对表T2收集统计信息，并且以估算模式，采样的比例为15%：

zx@ORCL>analyze table t2 estimate statistics sample 15 percent for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是估算模式所以估算结果和实际结果并不一定会完全匹配，比如表T2的实际数量与估算出的数量不一致。

只对表T2收集统计信息，并且以计算模式：

zx@ORCL>analyze table t2 compute statistics for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在对表T2的列OBJECT_NAME和OBJECT_ID以计算模式收集统计信息：

zx@ORCL>analyze table t2 compute statistics for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看出，现在列OBJECT_NAME和OBJECT_ID确实已经有统计信息了

注：在崔华老师的《基于Oracle的SQL优化》一书中提到T2原有的统计信息已经被抹掉了，也就是说对同一个对象而言，新执行的ANALYZE命令会抹掉之前ANALYZE的结果。但是在我实际的执行结果是表T2原有的统计信息没有被抹掉。我用到的环境是10.2.0.4和11.2.0.4，暂时没有11.2.0.1的环境。

可以使用如下的命令同时以计算模式对表T2和列OBJECT_NAME、OBJECT_ID收集统计信息：

zx@ORCL>analyze table t2 compute statistics for table for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看到表T2和列OBJECT_NAME、OBJECT_ID上都有统计信息了。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>analyze index idx_t2 compute statistics;

Index analyzed.

再次执行sosi脚本，从输出可以看到，现在索引IDX_T2已经有了统计信息，并且之前收集的表T2和列OBJECT_NAME、OBJECT_ID上的统计信息并没有被抹掉，这是因为我们刚才执行的ANALYZE命令和之前执行的ANALYZE命令针对的不是同一个对象。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>analyze table t2 delete statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，刚才收集的表T2、表T2的列OBJECT_NAME、OBJECT_ID以及索引IDX_T2的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列和表T2上的所有索引的统计信息，执行如下的语句就可以了：

zx@ORCL>analyze table t2 compute statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，现在表T2、表T2的所有列和索引IDX_T2的统计信息都有了。

1.2用DBMS_STATS包收集统计信息

从Oracle 8.1.5开始，DBMS_STATS包被广泛用于统计信息的收集，用DMBS_STATS包收集统计信息也是Oracle官方推荐的方式。在收集CBO所需要的统计信息方面，可以简单的将DBMS_STATS包理解成是ANALYZE命令的增加版。

DBMS_STATS包里最常用的就是如下4个存储过程：

GATHER_TABLE_STATS：用于收集目标表、目标表的列和目标表上的索引的统计信息。
GATHER_INDEX_STATS：用于收集指定索引的统计信息。
GATHER_SCHEMA_STATS：用于收集指定schema下所有对象的统计信息。
GATHER_DATABASE_STATS：用于收集全库所有对象的统计信息。

现在介绍DBMS_STATS包在收集统计信息时的常见用法，还是针对上面的测试表T2，这里使用DBMS_STATS包实现了和ANALYZE命令一模一样的效果。

先删除表T2上的所有统计信息

analyze table t2 delete statistics;

只对表T2收集统计信息，并且以估算模式，采用的比例同样为15%：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>15,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的估算模式，所以估算结果和实际结果并不一定会完全匹配。

需要注意的是，这里Oracle数据库的版本是11.2.0.4，我们在调用DMBS_STATS.GATHER_TABLE_STATS时指定参数METHOD_OPT的值为'FOR TABLE',这表示只收集表T2的统计信息。这种收集表统计信息的方法并不适用于Oracle数据库所有的版本。例如这种方法就不适用于Oracle10.2.0.4和Oracle10.2.0.5，在这两个版本里，即使指定了'FOR TABLE'，Oracle除了收集表统计信息之外还会对所有的列收集统计信息。

如果公对表T2收集统计信息，并且是以计算模式收集，用DBMS_STATS包实现的方法就是将估算模式的采样比例(即参数ESTIMATE_PERCENT)设置为100%或NULL；

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>NULL,method_opt=>'FOR TABLE',cascade=>false);

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2的统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在我们来对表T2的列OBJECT_NAME、OBJECT_ID以计算模式收集统计信息(不收集直方图)：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'for columns size 1 object_name,object_id',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在表T2的列OBJECT_NAME、OBJECT_ID上都有统计信息了，并且Oracle还会同时收集表T2上的统计信息(注意，这和ANALYZE命令有所区别)。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>exec dbms_stats.gather_index_stats(ownname=>'ZX',indname=>'IDX_T2',estimate_percent=>100);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在索引IDX_T2已经有了统计信息。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>exec dbms_stats.delete_table_stats(ownname=>'ZX',tabname=>'T2');

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，表T2、表T2的所有列及表T2的所有索引的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列及表T2的所有索引的统计信息，执行如下语句就可以了

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,cascade=>true);

PL/SQL procedure successfully completed.

1.3 ANALYZE和DBMS_STATS的区别

从上面的演示中可以看出ANALYZE命令和DBMS_STATS包都可以用来收集表、索引和列的统计信息，看起来它们在收集统计信息方面的效果是一模一样的，为什么Oracle会推荐使用DBMS_STATS包来收集统计信息呢？

因为ANALYZE命令和DMBS_STATS包相比，存在如下缺陷：

ANALYZE命令不能正确地收集分区表的统计信息，而DBMS_STATS包却可以。ANALYZE命令只会收集最低层次对象的统计信息，然后推导和汇总出高一级的统计信息，比如对于有子分区的分区表而言，它只会先收集子分区统计信息，然后再汇总，推导出分区或表级的统计信息。有的统计信息是可以从当前对象的下一级对象进行汇总后得到的，比如表的总行数，可以由各分区的行数相加得到。但有的统计信息则不能从下一级对象得到，比如列上的distinct值数量NUM_DISTINCT以及DESNSITY等。

ANALYZE命令不能并行收集统计信息，而DBMS_STATS包却可以。并行收集统计信息对数据量很大的表表而言，是非常有用的特性。对于数据量很大的表，如果不能并行收集统计信息，则意味着如果想精确地收集目标对象的统计信息，那么耗费的时间可能会非常长，这有可能是不能接受的。在Oracle数据库里，DBMS_STATS包收集统计信息可以并行执行，这在一定程度上缓解了对大表的统计信息收集过长所带来的一系列问题。

DBMS_STATS包的并行收集是通过手工指定输入参数DEGREE来实现的，比如对表T1进行收集统计信息，同时指定并行度为4：

exec dbms_stats.gahter_table_stats(ownname=>'SCOTT',tabname=>'T1',cascade=>true,estimate_percent=>100,degree=>4);

当然，DBMS_STATS包也不是完美的，它与ANALYZE命令相比，其缺陷在于DBMS_STATS包只能收集与CBO相关的统计信息，而与CBO无关的一些额外信息，比如行迁移/行链接的数量(CHAIN_CNT)、校验表和索引的结构信息等，DBMS_STATS包就无能为力了。而ANALYZE命令可以用来分析和收集上述额外的信息，比如analyze table xxx list chained rows intoyyy可以用来分析和收集行迁移/行链接的数量，analyzeindex xxx validate structure可以用来分析索引的结构。

2、查看统计信息

前面介绍了如何收集统计信息，那如何查看这些统计信息呢？Oracle数据库的统计信息会存储在数据字典里，我们只需要去查询相关的数据字典就好了。如果有充裕的时间，现写SQL去查询数据字典里的统计信息也没有什么，但当我们真正碰到有性能问题的SQL时，通常会希望能在第一时间就收集到与目标SQL相关的各种统计信息，以便于在第一时间定位问题所在，这时候写SQL去查询数据字典就已经来不及了，所以我们需要事先准备好通用的查询统计信息的脚本，出问题的时候只需要运行一下脚本，就能在第一时间获取目标对象的所有统计信息了。

sosi脚本(Show Optimizer Statistics Information)就是这样一种脚本，国内的Oracle数据库专家也一直在用这个脚本，它源于MOS上的文章：SCRIPT - Select to show OptimizerStatistics for CBO (文档ID 31412.1)，用法很简单，只需要运行一下sosi脚本，并指定要查看统计信息的表名就可以了。它支持分区表，显示分为三部分，分别是表级别的统计信息，分区级别的统计信息和子分区级别的统计信息。前面做实验用到的也是这个脚本。

附件是sosi脚本可以下载使用。

参考《基于Oracle的SQL优化》

海康威视：形成软件开发方法论，社会经济到了由商业需求拉动的时代

Sat, 29 May 2021 17:56:00 CST

近日，海康威视举行投资者问答会议。

在AI市场机会上，海康认为AI的机遇已经得到行业普遍认同，未来AI成本会持续降低，AI技术在改善产品性能上作用很大，AI算法和大数据等，会带来许多之前想做但做不到的业务机会，也会开拓新玩法，未来会打开更多市场。

在软件投入上，组件化的开发已经是海康确定的软件开发方法论。近几年海康的软件开发环境、管理环境、运维环境的使用都已经成熟，过程更规范、更有效率。未来PaaS、DaaS、SaaS层面都有更多的事情可做，海康各个层次的软件研发管理维护的资源团队都会再进一步加大投入。

海康从可见光走向全光谱，发力多维感知，是作为一家做物联网、大数据的公司必然选择，既然是必然选择就先不考虑产出比。海康预期三年未来市场端变化将非常复杂，对海康靠技术创新的公司将有更多机会。

未来10年，创新业务保持更快增长的确定性较高。

未来几年，三个BG都将有不错发展，受不同因素影响会有阶段快慢。

PBG会受限于地方政府的财政和疫情，但政府项目的数据规模大、应用复杂程度高，会一直是应用高地，也会有新的业务形式；

EBG从长期看比PBG市场更大，社会的经济增长到了更多由商业需求拉动的时代；

SMBG会围绕服务渠道伙伴、工程伙伴，连通线上线下，提高运转效率，改善生态，扩大海康的业务影响力。

尽管未来有诸多不确定性，但海康的销售和研发的费用投入上，必须做两件事：

一事平台的搭建与持续维护，与行业应用不断做新的融合；二是产品，基于创新业务和基础技术开发上的产品。

做企业既要有风险管控能力，也需对保持对机会的追求。

以下是调研全文重要内容，雷锋网作了不改变原意的整理与编辑：

Q：目前AI的应用逐渐落地，公司觉得国内外市场机遇怎么判断？

A：经过过去几年的发展，行业中的玩家已经更加认同，AI是个基础技术，在很多方面都会发挥作用。未来AI的成本还会持续的降低，AI技术在帮助产品性能的优化和改善上帮助是很大的，由此会打开越来越多的市场。

AI的算法和大数据相关的应用，会带来许多以往我们想做但是做不到的业务机会，也开拓更多新技术平台上的新玩法。

国内的应用走得快一些，但很难说用我们在国内锻炼出来的产品和方案直接复制海外市场。海外市场对AI应用的观点不同，AI应用的发展节奏也不同，不同国家和地区之间的发展路径也是不一样的。还是要根据每个国家每个地区的不同需求，来制定不同的产品策略与方案。

Q：算法、数据对业务越来越重要，也看到海康为了适应对算法和数据的开发而在软件开发的方式上不断转型，用组件为基础开发软件已经看到很多成效，未来的软件投入主要是什么层次和方向上的？

A：过去几年海康谈的比较多的是统一软件架构，组件化的开发已经是公司确定的软件开发方法论，也是用来整合各个团队开发资源的基础。

这几年的软件开发环境、管理环境、运维环境的使用也都已经成熟，这些环境能保障软件开发和管理维护的过程更规范，更有效率。

在这些基础能力上，我们也在针对数据和应用做很多工作，做PaaS和DaaS，把PaaS和DaaS4这两层搭起来用起来，现在已经有一些应用和模型基本上成熟了。

SaaS部分海康和伙伴们分工协作，直接面对用户场景做定制开发。随着我们统一软件架构这个整体方法论的成熟，以及方法论之下各种技术工具不断被打磨，我们有了将应用和数据做深做厚的能力，也有了协调更多的软件研发资源，做更大规模开发的能力，未来PaaS、DaaS、SaaS层面都有更多的事情可做，我们的产品会更加丰富，公司各个层次的软件研发管理维护的资源团队会再进一步加大投入。

Q：年报中判断未来三年是机遇期，也提到了海康正在从可见光走向全光谱，请问从可见光走向非可见光的部分，公司要怎么投入，能带来多少回报？

A：非可见光在场景中最重要的作用在于，在某些场景下，某种感知方式可以发挥不可替代的作用，比可见光会更加有效，即使只在整体方案中占不多的比例，但作为补充会非常有价值。

对于投入和回报，在初始阶段我们对产出不是特别关心，早期也不知道会做成怎么样。只是觉得对海康来说作为一家做物联网、大数据的公司，多维感知是我们必然的一个选择，既然是必然选择就先不考虑产出，效果交给时间。

未来三年我们预期市场端的变化将是非常复杂的，包括逆全球化的趋势、上游供给侧的变革，会带来很多产业的结构发生深刻的变化。未来几年，尤其是像我们这样靠技术创新发展的公司来说，应该有更好的机遇。

Q：如果未来三年是海康的一个大发展阶段的话，三个BG和创新业务的收入占比会是一个什么样的分布？

A：创新业务整体来说占比还小，但是我们的创新业务很聚焦，可以和海康在技术能力、客户资源、产业链配合上有很强的协同效应，所以创新业务在下一个10年中保持更快的增长都是确定性比较高的。

未来几年，三个BG都会有不错的发展，但是受到某些因素的影响，会出现阶段性的有快有慢，会不一样。

PBG在过去2年多的时间里受限于地方政府的财政状况，今天疫情之下政府也在继续为企业降低负担，也在削减自身的财政收入，但是政府项目的数据规模大，应用复杂程度高，会一直是应用的高地，也会不断有新业务形式发展出来，带动公司的进化。

从长期发展来看，EBG应该比PBG要大一些，社会也到了经济增长更多的由商业需求拉动的时代。SMBG方面我们会围绕服务渠道伙伴、工程伙伴做更多的工作，连通线上线下，让我们生态里的行业从业者更专业、更规范的开展工作，也用互联网后台的建设和管理帮他们提升运转效率，通过他们扩大海康的业务影响力。

Q：海康的费用率从季度环比看是往下走的，在销售费用和研发费用的投入上接下来是什么节奏？

A：未来还有很多不确定性，我们肯定会做很多事情。

一是平台搭建，还需要不断的维护，更多的行业应用会起来，会有一些新的融合；

二是产品，包括在创新业务、在基础技术开发上面，未来可能都会有大的变化。

在当前国内大循环和国际双循环的大环境下，中国和美国在高科技上的投入态势会和过去20年有很大的差别，中国的科技产业的地缘分布结构可能会有很大的调整。

我们相信在包括半导体、高科技、材料、基础算法等很多方面，中国企业在未来10年、15年会有很大的发展空间，这是我们看到的机遇，也要抓住这个机遇，保持相当的投入力度。费用率未来还是会继续往上走，我们做企业既要对风险有能力管控，也要对机会保持追求。雷锋网雷锋网雷锋网

你可能不信，领先80%的人的方法其实很简单

Thu, 07 Jan 2021 14:07:03 CST

前言

工作16年，我观察到一个很出乎意料的现象：

很多年轻时脑筋活泛、不甘下游的人，到了四十岁似乎也没有领先别人多少，甚至有不少人还落后了。

而年轻时能力一般、安于现状的人，到了四十岁似乎也普遍在经理、总监的位置上，甚至还有人担任了总经理。

是什么造成了这种预期外的情况呢？

我将我这十多年接触过的上千人捋了下，发现了一个规律： “出类拔萃很难，但领先80%的人却很简单”。

只要做到以下四点中的任一点，几乎人人都能成为领先的前20%。

01
多点耐心

第一点是多点耐心。

在现在这个一切都讲究快节奏的社会里，有耐心的人实在太少了（绝对少于20%）：

学习某个技能刚三天，就觉得见效太慢选择放弃。

工作刚半年没加薪，就觉得受委屈要离职。

创业时在产品上没耐心打磨，成天想着怎么融一大笔钱、怎么用户裂变一夜暴涨。

所以，如果你能多一点耐心，比别人多坚持一会儿，很容易就能领先这80%没耐心的人。

我刚毕业那会，也是一个没耐心的人。

我2004年大学毕业时，进的第一家公司是一家IPO中的行业领头羊，号称是行业里的“黄埔军校”，发展前景极好。

我是通过公司”百名名校生计划”的校园招聘加入的，因为这个计划才实施第二年，而且前一年公司才招了3名名校毕业生，所以我们这批毕业生一入职，公司就给了很高的职级起点。

但我在公司呆了一年后，虽然拿了部门最优，工资也是同期应届毕业生里最高的，我却依然觉得公司的平台不足以支撑我更快成长，因此选择跳槽了。

这个决定的后果是，当我离开2年得意于一万多元月薪的“高薪”时（2006年月薪8000都算挺高的了），留下的同学少的有几百万股票市值，多的有几千万。

在2007年之前能有这个身家，已经算是摸到财务自由的边了。

尝过了这一次没耐心的苦果后，我就告诉自己一定要有耐心，坚持长期主义，在任何一家公司都至少要呆满三年。

有了这个转变，我之后的职业生涯收获了越来越来的长期主义回报。

比如，我在IBM时虽然经历了多次团队动荡，90%的同事都选择离开团队甚至公司。

但因还未满三年，我就咬牙坚持了下来，从而获得了团队重建后的一个大机会——担任事业线管理咨询团队的负责人。

如果不经历团队重建，这个机会根本不可能落到我这种不足30岁的顾问身上（前一任负责人是40多岁）。

正是有了这个机会，也让我有了更多咨询和管理经验的积累。

同样的耐心，我也带到了YouCore的创业中。

在2015年~2017年知识付费的疯狂中，愿意沉下心来做产品的人极少，因为赚钱太容易了。

随便粗制滥造一个产品，只要推广做得好，就能卖几万、十多万份，一下子就几百、上千万的收入，谁还愿意“浪费”时间在产品打磨上？

但我们抵制住了这波诱惑，认真打磨产品，到2018年知识付费退潮时，YouCore反而逆势增长，学员规模、业务收入和口碑都越来越好。

因此，让自己多一点耐心，你会发现不经意间就领先80%的人了。

02
多点行动

第二点是多点行动。

如果你稍微用心观察下周边的朋友和同事，你会发现坐而论道、大谈理想的人很多，但是踏踏实实动手去做的人却很少。

比如，做个逻辑顺序练习，有些同学会跟我讨论逻辑顺序的本质是什么，是不是所有的事都一定能按逻辑顺序组织，太关注逻辑顺序是否会影响大脑的创新等等。

他们美其名曰这叫探究概念的本质，是更高级的思考和学习活动。

探究概念的本质确实是一种高级的元认知活动，但问题在于他们探究得太多，动手得太少。

结果就是高谈阔论了一大堆的本质和原理，但连一个最基本的“如何做好自我介绍”的逻辑顺序都组织不好。

我其实并不反对探究概念的本质，在我写的《学习力》这本书中，就专门有一章讲探究概念本质的方法。

但这个探究是建立在先照着生搬硬套，做了之后再来探究的，而不是动手前就先高谈阔论。

带过这么多同学的逻辑顺序练习，我发现的一个扎心事实是：

脑子灵活，一开始理解就有70分的同学，如果光高谈阔论不充分练习，一个月后对逻辑顺序的理解和运用水平依然还是70分上下。

但哪怕脑子没那么灵活，一开始理解只有30分的同学，认认真真去完成了10~20个练习后，对逻辑顺序的理解和运用水平没有一个是低于80分的。

为什么只要充分练习了，理解水平就能从30分跑到80分以上呢？

因为只要去做了，就会发现疑惑和差距，有了疑惑和差距，自然会找老师来解答，再经过练习验证，自然就理解得越来越深了。

这就是“纸上得来终觉浅，绝知此事要躬行”的最佳写照之一。

逻辑顺序练习如此，写文章也是如此。

总有同学跟我取经如何写好文章，有没有什么写作方法论？

我的最大建议就是：不用管什么方法论，先去写，写多了你写作水平就上来了。

因为写多了，你就不得不去琢磨新的写作内容从哪儿来，怎样写更吸引人、如何写才更高效等等，写作水平自然也就高了。

但如果不去写，再厉害的写作方法论给你也没啥用。

所以，少一点空想，多一点行动，你想不领先80%的人都难，因为愿意动手去做的人实在是太少了。

03
少点贪心

第三点是少点贪心。

今天早上又有位同学发消息给我说：

“老师，我最近很焦虑，感觉前面有很多问题要解决，有很多东西要学，焦虑反过来又让我很拖延，感觉成长很慢。

我应该怎么来设定我的合适的目标和成长计划？”

这个问题非常具有普遍性，80%以上的人都有。

这种焦虑的根本病因在于贪心。

得到的太少，往往是因为我们想要的太多。

管理学大师德鲁克在《卓有成效的管理者》中有一段讲得特别好：

有些人一事无成，而实际上他们却做得很吃力。原因有三：

第一，他们低估了完成一件任务所需的时间。他们总以为万事顺利，却总不免有出乎意料的情况发生...

第二，一般的管理者（往往也是不大有效的管理者）总喜欢赶工——而赶工的结果，总不免使进度更加落后...

第三， 一般的管理者喜欢同时着手几件要事，结果对每一件事，他们都无法获得足够的最少整块时间。只要任何一件事情受阻，全部事情也都会跟着受阻了。

——引自德鲁克《卓有成效的管理者》

如果我们能减少自己的贪心，像德鲁克建议的这样，一段时间只聚焦一个目标、一个关键任务的话，那么我们成功完成这个目标或关键任务的概率将大大提高。

有些同学可能会担心：目标或计划安排得太少，是不是会导致完成的任务总量减少？

其实如果你减少了计划中的工作量，还是未能按时完成，那么你在计划里加再多任务项也没意义，反正你都不会去做。

而且，你排上这些事项，只会导致原本能做完的要事因为受到干扰做不完，结果就是更焦虑，导致什么都不愿做了（反正也做不完）。

假如真的将任务量排少了，你最终做的事也不会变少，因为你肯定有多余的时间空下来，那时再加更多的事就可以了。

这种减少贪心排计划的做法，就是YouCore提倡的周计划做法（公众号回复“周计划”，可领取一个弹性十足、聚焦要事的周计划模板）。

只要你肯让自己少一点贪心，你就会有跟下面这位同学一样的欣喜收获。

04
少点娱乐

第四点是：少点娱乐。

这个建议提出来可能会被80%以上的人骂。

这就对了！

正是因为80%以上的人都不愿意放弃娱乐，所以只要你愿意牺牲部分娱乐活动，你很轻松就能领先他们了。

在现在这个全球消费主义占主流的时代里，人类社会和文化有了越来越强的娱乐化倾向。

《美丽新世界》的作者英国作家赫胥黎曾警告过：

在一个科技发达的时代里，造成精神毁灭的敌人更可能是一个满面笑容的人，而不是那种一眼看上去就让人心生怀疑和仇恨的人。

让你趋之如骛的手机游戏、刷了就放不下的短视频、无脑连续剧、低俗综艺节目正是这个“满面笑容的人”。

世界著名的媒体文化研究者尼尔·波兹曼在1985年出版的《娱乐至死》中，就因为电视文化的盛行提出过一个著名预言：

毁掉我们的不是我们憎恨的东西，恰恰是我们热爱的东西！

教育、体育、商业和任何其它公众话语的内容，都日渐以娱乐的方式出现，并成为一种文化精神，而人类无声无息地成为娱乐的附庸，毫无怨言，甚至心甘情愿，其结果是我们成了一个娱乐至死的物种。

以现在很出名的几款手机游戏为例，称之为新时代的“鸦片“都不为过。

有人也许会跳出来举少数的几个个例来反驳我：我表哥就很爱玩游戏，但他就考上了985大学。

嗯，也许你表哥是因为玩游戏才考上985大学的！

但99.99%的人如果爱玩游戏，大概率考上一本都有困难。

我自己也曾是游戏的重度爱好者，上大学时曾经一个学期光玩游戏不学习。

我毕业的学校算是中国顶级的名校之一了，我可以用亲身经历负责任地告诉你：不沉迷玩游戏的985高校学生会更优秀。

至少我工作后戒掉游戏，体验到了一种更积极的状态时，就很后悔大学时荒废了很多时间在游戏上。

因为享受到了戒除游戏带来的好处，我后来也从来不看低俗综艺节目、不追无脑连续剧、不刷短视频，这帮我省下了大量的时间，也大大减少了意志力的消磨（手机游戏和短视频的最大危害之一是会消磨一个人的意志力和自控力）。

我不反对娱乐，在合理范围内娱乐，会给我们带来精神的享受和精力的恢复。

但现在的问题是，太多的人不是娱乐不足，而是沉溺在了尼尔·波兹曼所预言的“泛娱乐”之中。

所有这些泛娱乐的东西，利用的都是人性中贪婪、懒惰、虚荣的一面，很容易就让你上瘾，你一旦上瘾绝对是百害而无一利的。

所以，如果你能抵制住诱惑，减少一点娱乐的话，你会发现你比80%的人都多了不少可用于学习和思考的时间。

05
小结

出类拔萃很难，但领先80%的人却很简单，真的只要投入20%的努力就能做到。

多点耐心、多点行动、少点贪心、少点娱乐，这四点里只要你能做到其中一点，领先80%的人几乎就是顺其自然的事。

如果四点你都能做到的话，那么成为出类拔萃的人也很有可能。

如果你有所怀疑的话，请你挑选其中一点认真去实践上三年，你就会知道此言非虚了。

这是YouCore在2021年的第一篇推文，在此借这篇文章祝你早日领先80%的人！

文：王世民（深圳尔雅总裁 | YouCore创始人；著有《思维力》《学习力》《个体赋能》；文章首发于微信公众号YouCore，专注于个人核心通用能力的提升：思维力、学习力、人脉力。以及解决工作三年以上会碰到的实际问题，如缺乏深度思考、知识体系不完善、人际交往不顺利、晋升瓶颈等。感兴趣的可以关注一下公众号，查看更多干货文章。）

责任编辑：殷水

业务和流程驱动的SOA服务识别方法总结(201223)

Wed, 23 Dec 2020 21:14:13 CST

今天整理和分享下流程驱动的SOA服务识别方法，该方法在传统SOA架构规划咨询中应用比较多，对于当前的微服务架构规划咨询仍然可以参考借鉴。

服务识别整体流程说明

服务识别和服务需求分析的主要工作是基于SOA的需求分析方法论，以流程和业务驱动IT的指导思想，对业务系统进行业务建模，用例建模和业务实体建模，形成企业级需求和业务功能清单，作为后续服务识别的输入。

对于服务需求，以流程分析为基础，通过流程的逐层分解，细化出关键的业务活动，将流程活动识别为业务用例，并对业务用例进行建模。用例建模本身可以作为业务系统功能开发的需求规格说明书，同时对用例分析和功能操作的识别形成业务域-》流程分解-》用例-》业务操作的分解过程，用于后续服务的识别。

在整个分析过程中，流程的关键活动或业务用例的操作都会涉及到业务实体对象，因此需要对业务实体对象进行单独建模，分析实体对象的关键属性和对象间关系，同时分析实体对象和业务操作间的U/C矩阵，作为后续公用服务提取的基础。

服务识别开始于需求分析，终止于识别出的候选服务列表。为了有效的实施SOA工程，应用不能孤立于其他应用而独立开发。SOA的应用应该可以共享服务，这些服务不单单属于某个独立的应用，并且有自己的生命周期，能够被独立的管理。在SOA工程中，为了有效的管理需求，各个项目必须知道其他已经存在的项目、正在开发的项目以及未来将要开发的项目需求。所以，与SOA服务相关的需求应该在企业级层面管理。

对于服务本身可以分为业务服务，数据服务，技术服务等。从上图也可以看到通过业务流程分析和业务架构梳理来识别业务服务；通过数据架构和数据建模来分析和识别数据服务；通过技术架构分析来识别关键的技术服务能力。

候选服务是被识别出用于系统重用的业务功能。一个候选服务不一定一对一的对应到实际交付的服务，比如，在分析阶段，一个粗粒度的服务可能对应到需求中两个或两个以上的初始候选服务。另一方面，服务识别并不是简单的识别出候选服务，也包括了一系列的校验和评估。

服务识别整体方法

对于服务识别的方法，在前面很多文章都已经讲到过，对于SOA实施中服务识别是相关重要的一个环节，如何基于业务驱动IT的思路，识别出真正粗粒度，高度自治，可复用的服务是后期服务治理管控能否顺利的一个关键。否则SOA建设到后期很容易就变成一个数据集成平台，而非是服务共享平台。要知道服务的本质还是接口和交互，因此对于服务的识别总体来说两种方法：


   自顶朝下：基于业务流程分析入手，分析跨系统业务流程交互，识别出集成点和接口点，再转化为服务
自底朝上：基于当前遗留系统已有的系统间接口情况，分析接口对应的业务场景，再进行接口转服务

可以看到不论是哪种方法，这里面都有两个重点，其一是必须要明确的清楚每一个服务的业务含义，对应的业务场景和业务交互点在哪里？其次就是需要做接口转服务这个关键动作。

1. 自顶朝下的服务识别

如果各个业务系统之间没有业务和数据的交互，那么跟根本不应该存在任何的接口或服务。而对于服务的存在原因主要还是我们的端到端业务流程往往是跨了多个业务系统的交互才能实现的，而这些跨业务系统的交互点要么进行业务规则的校验，要么进行关键业务数据和单据的传递。

这些交互点和集成点都是潜在的接口服务识别点，通过这种方式识别出来的服务我们就很清楚服务对应的业务流程和场景。比如采购系统和ERP之间有一个采购订单导入的接口服务，我们就很清楚整个供应链流程中，采购订单的创建和生效是在采购系统里面，但是基于采购订单的采购接收和入库是在ERP系统，因此需要将采购订单同步到ERP系统中。

这种跨系统流程分析基本会把横向的所有关键接口全部梳理出来，但是容易遗漏掉纵向的一些基础数据共享接口，距离来说我们在拟制采购订单的时候，是需要输入和选择项目信息，选择对应的库存组织信息的。而这些基础数据需要从项目管理系统和ERP系统中同步过来。但是在流程图中往往只会有采购订单创建节点，因此容易遗漏这些基础数据共享接口。

还有就是某一个业务功能在实现过程中，可能涉及到调用外部的业务规则和逻辑，这种交互点也容易遗漏需要特别注意。举例来说，采购订单在创建完成的时候并提交的时候需要检查预算是否足够，而这个检查规则逻辑是预算管理系统实现的，因此在这里也存在采购系统和预算系统间的业务接口和服务。

2. 自底朝上的服务识别

特别遗留系统环境进行SOA架构改造和服务接入的时候，我们要意识到必须要将遗留系统间的当前已有接口全部分析和梳理清楚。因为既然当前遗留系统能够正常运作，也能完成跨系统的业务交互，那么原来的接口从面上是完全能够覆盖业务需求的，我们唯一要考虑的是接口本身的定义和设计是否合理的问题。

当整理出完整的接口清单后，我们要做的就是搞清楚每一个接口对应的业务场景究竟是如何的？基于这种反向思路我们只关系和接口相关的业务交互场景，而不是关注全部业务流程。搞清楚了具体的业务场景后，接着要做的重点工作就是对接口进行评估，接口的评估主要包括了如下内容：


   a) 接口当前使用频度如何？是实时还是定时同步？同步频率能否满足业务的要求？
b) 接口传递的数据量如何？当前在数据传递的时候有无性能问题？
c) 接口本身的实现方法是如何的？比如Dblink，存储过程，WS接口，还是直接原始的JDBC接口等。
d) 接口本身的复用度如何？相关类似的接口有哪些？相互之间有哪些差异？

做了接口评估最主要的仍然是要考虑如何进行接口去重和接口合并，对于接口转服务的方法，我前面有专门一篇文章再谈，在这里就不再展开。

本身相互独立的两个业务系统，比如A系统和B系统，按道理两个系统应该完全独立，包括数据库，中间件，应用部署包等。两个系统之间只能通过标准的接口进行业务和数据的交互。但是实际在项目实施中发现一种普遍存在的现象，即A系统将自己的数据库账户完全开放为B系统，而B系统在拿到数据库连接串信息后，通过自己编码实现完全可以对数据库A中的数据库表进行各种任意的CRUD操作。

在这种情况下可以看到，A和B两个系统之间已经完全耦合在一起，这个时候A系统要做数据库层面的迁移和数据库表结构的变更往往全部会影响到B系统。如果要把这些接口点找到，必须要把B系统中的所有代码进行遍历查找和分析，往往才能够找到具体的接口点有哪些。这些不规范的使用方式都对后续的SOA服务改造和迁移造成相对重大的影响。

业务建模

业务建模包括了业务调研，业务流程分析，全局用例建模和全局数据建模几个关键内容。其中核心仍然是基于业务流程驱动，基于流程分析来识别关键的业务用例和业务对象。

业务调研

该部分包括业务需求调研，包括业务流程或问题产生的背景介绍，具体的业务需求收集和分类。现有的业务流程现状，业务需求所在的具体业务域，涉及到的岗位角色人员信息等。业务调研包括了业务流程，业务数据，业务系统三个方面的内容，业务调研内容具体输出为业务调研文档。

业务调研完成后应该输出完整的业务流程调研报告，其中也包括了对业务系统间交互接口的调研和现状梳理。

流程分析

流程分析需遵循端到端流程分析的思路，对流程进行二级，或三级分解。流程分析前可以先进行主题域分析，绘制上下文关系图，通过上下文关系图来进一步识别关键业务流程。具体参考流程分析指导书。

通过上下文关系图对主题域进行分析后，可以得到主题域中所包含的业务事件，而这些业务事件就是业务流程的起点。流程分析时，需要注意流程的目标性、内在性、整体性、动态性、层次性、结构性这六大特性，流程是需求分析的重要内容，流程图对于和用户确认需求以及向开发团队传递需求都是非常重要的。可以选择使用UML规范中的活动图或商业建模标准中所推荐的跨职能流程图对流程建模。

通过流程分析可以进一步明确流程的的关键业务活动，每个业务活动的输入，输出，涉及的岗位角色，传递的业务数据等关键内容。具体流程分析输出包括：

业务系统所涉及的端到端业务流程图
业务域的业务流程分解图
针对业务流程图进行的详细业务流程活动和输入、输出描述

全局用例建模

根据业务域划分和业务流程分析，进行用例的识别，流程中清晰地表达了角色所要执行的业务活动，这正是用例的内容，用例即用户使用系统完成业务活动的场景在将业务活动及报表转换为用例后，使用UML中的用例图对用例建模，用例图不但可以表达出用户是如何使用系统的，还可以表达出用户与用户之间的关系，用例与用例之间的关系。

对于流程图转换到用例的具体方法，可以参考需求分析指导书中的详细说明和转换原则。对于业务用例分析和建模基础，请参考UML相关文档。

全局数据建模

本部分主要是根据流程分析和用例建模，抽取流程和用例中的关键业务实体对象进行数据建模分析。全局数据建模只需要分析出关键的业务实体，实体描述和实体之间的关系即可，在业务实体建模环节讲进一步对该部分内容进行细化分析。

全局数据建模需要输出数据概念模型，数据实体对象清单和实体描述信息。

用例建模

用例建模首先是流程建模中的关键业务活动会转化为用例，这在全局用例建模中会进行分析。从流程图中转换用例时，先基于流程图分析流程图中的职能带区(泳道)哪一些是不直接使用系统，将其排除，将余下的职能带区(泳道)转为角色，将流程图中的业务活动及判断转换为用例，决定活动是否要转换为用例的标准是它是否属于系统范畴，而决定判断是否要转换为用例的标准是它是否独立。

用例建模需要参考用例编写标准模板进行用例的编写，针对每一个用例需要填写的内容主要包括如下：

用例的编号，名称，级别等信息。

用例执行的上下文背景介绍

用例执行的前置条件，后置条件，最小保证

用例执行的基本流

用例执行的扩展流

业务规则信息

假设和约束信息

其它备注或说明信息

业务操作分析

在用例建模的过程中，用例本身即是一个实现业务价值的交互业务活动集合。因此可以对用例进一步分析，识别更细粒度的业务活动和操作，这些业务活动或操作可以从基本流，扩展流和业务规则中寻找。业务操作分析要求如下：

业务操作即业务活动中的业务任务，有明确的业务含义

业务操作本身是可复用的业务单位

业务操作本身采用动宾结构进行描述

 业务操作本身具有高内聚，松耦合性的自治性

数据建模

业务实体分析

用例模型只是对用户如何使用系统的业务场景进行建模，如果要构建系统，还需要对系统的框架进行建模，即要弄清楚目标系统所要管理的“物”：业务实体，并弄清楚这些业务实体间的关系。

在对业务实体建模时，一般是使用“名词动词法”识别出业务实体，并逐步确定实体间的关联关系及其属性。

对业务实体建模选择使用UML规范中的类图或实体图作为模型，类图/实体图中的一个类/实体表达一个业务实体，类/实体的属性用于对业实体的属性建模，而它们之间的关系则可以用来对业务实体间的关联关系建模。对于比较复杂的业务实体，还可以采用UML规范中的状态图对其建模，可以表达出业务实体的状态切换与触发事件的关系。

业务实体分析中需要对识别的业务实体详细描述业务实体的数据字典信息，包括业务实体中各个数据项的类别，长度，完整性规则，业务用途等相关信息。

实体使用U/C矩阵分析

实体使用分析主要包括业务实体跨系统使用情况分析和业务实体系统内使用情况分析两方面的内容。

跨系统使用情况分析，主要是为公共数据服务的提取做准备，在该分析矩阵中需要列出业务系统产生的关键业务实体，分析这些业务实体在MSS域相关业务系统中的CRUD情况，作为后续数据服务识别的一个输入。

业务实体系统内使用分析，主要分析系统内关键业务实体和业务用例之间的对应关系，找寻系统内可复用的业务操作，为系统内服务识别做准备。

服务识别

数据服务识别

数据服务为以实现业务系统底层数据集成为目的，以业务实体为核心的数据对象传输为主的SOA服务。数据服务没有明确的业务规则和含义。一般服务消费方在消费数据服务后都需要将数据同步到本地数据表，再根据业务系统自身需要对数据服务进行相关业务规则的封装和实现。

01 业务实体确认

在业务建模和数据建模阶段，已经对业务实体进行了分析，包括业务实体的类型，业务实体和业务功能的U/C矩阵分析等。业务实体是识别数据服务的基础，因此需要对业务建模阶段识别的业务实体进行确认。业务实体完全是业务视角的业务对象，而不是数据库设计中的数据库表，如采购订单业务实体可能涉多层结构和多张数据库表，但是在此处的分析只需要考虑采购订单业务实体对象。

02 服务重用性分析

在业务建模构建的U/C矩阵的基础上，可以从两个层面分析服务的重用性。一个是跨业务系统的服务重用性，一个是在一个业务应用内部业务模块间的服务可重用性。当一个业务主数据或一个核心业务单据需要跨多个业务系统或业务模块使用的时候，则该业务实体识别为数据服务是可重用的。

03 服务实现方法分析

在服务实现的时候，一方面是考虑服务的可重用性，一方面是考虑业务敏捷要求。对于数据类服务一般可以实现为查询类数据服务，也可以实现为导入类数据服务。当业务数据的业务敏捷性和时效性要求高时候，优先考虑实现为导入和分发类服务满足业务敏捷性的要求。

04 服务大数据量传输分析

对于底层数据集成类服务，可能涉及到大数据量传输，这种数据对实时性要求不高，但是任何一个批次传输可能都在10万级以上的数据量。对于这种情况要单独进行分析，分析服务数据量，调用频度，数据同步机制等。对于大数据量传输在识别为数据服务的时候可以考虑ODI服务，JMS消息，数据分页等多种方式来实现。

业务服务识别

业务服务是有明确业务含义的，含具体业务规则和逻辑的，实现一个有价值的业务活动的一系列业务操作的组合。业务服务具有明显的高业务内聚性，粗粒度特征。

01 业务组件确认

业务组件是实现多个业务功能的，高内聚松耦合的业务功能模块单元。业务组件是可以进行独立需求分析，设计，开发，测试和部署的组件管理单元。

对于一个完整的业务系统或业务流程是通过业务组件的交互和协同来完成。业务组件之间的交互则通过标准的SOA服务方式进行。即业务组件中包含了技术组件和服务组件，其中服务组件暴露业务服务。

业务组件和服务的详细关系如下：


   1. 对SOA服务进行分析，可以从服务中发现组件。对服务进行组合、功能及UI界面封装可以形成新的组件，所以组件可以调用一个或多个SOA服务，成为服务的消费者；
2.   组件按照SOA服务识别规范，抽取服务，可以成为服务的提供者。

02 业务服务识别

对于业务服务识别分为两个层面的内容。其一是为了实现跨业务组件的业务流程分析出来的业务组件之间的业务交互。其二是在用例建模阶段我们对业务操作进行了详细分析，对于这些分析整理出业务操作清单，对于业务操作清单中的可重用的业务操作识别为关键的业务服务。具体识别步骤为：


   1.     根据业务流程或业务用例，绘制相应的跨业务组件协作的业务交互图。
2.   对所有的业务交互点识别为潜在的业务服务。
3.   对业务操作活动列表进行分析，将可重用的业务操作识别为潜在的业务服务。

UI组件服务识别

UI组件是可以完成独立的业务功能的小业务应用。UI组件可以独立进行需求分析，设计，打包，部署和运行。UI组件是一种页面内嵌的方式在多个业务系统中运行，因此在UI组件复用的情况下，基本不需要进行底层的数据集成和同步操作，可以更好的保证数据的一致性和时效性。

对于UI组件的识别主要分为两个层面进行：

从顶向下识别：对于业务系统在构建中的业务系统和系统需求进行分析，在系统需求阶段会进行详细的功能需求描述和UI界面描述。可以针对这些需求文档分析重复的业务功能界面，将其识别为潜在的UI组件服务。

从下向上识别：该方法是首先对业务系统中的平台化功能模块进行抽象，如工作流管理，系统管理，公共技术服务等都是可以进行平台化的组件功能模块。

对于平台化的组件功能模块需要和业务系统进行界面层的交互，因此对于这些界面层交互可以由平台层提供UI组件服务内嵌到各个业务系统中使用。

技术服务识别

技术服务是和业务无关的，提供某种技术能力的服务。技术服务一般包括消息，安全，日志，会话，规则，异常，数据库管理等多个方面的内容。对于技术服务的识别仍然是包括了两个层面：

从顶向下识别：在业务建模和业务系统需求分析过程中，需要关注业务系统非功能性需求的描述，这些非功能需求包括了异常，日志，安全，性能，可靠性，高可用性，可扩展性，大数据量处理等多个方面的内容。对于这些非功能需求如果有多个业务系统或模块提出，则可以考虑抽象识别为公有的技术服务。

从下向上识别：该方法是从平台层面进行考虑，企业在业务系统建设过程中一般会分为产品层和平台层，对于平台层又包括了产品平台和技术平台。

在进行平台化功能构建的过程中，平台层需要朝产品层提供能力，这些能力的提供都可以考虑以技术服务的方式统一提供。以实现产品层和平台层的集成。

流程服务识别

对于流程服务的识别，仍然是以前期输出的端到端流程梳理和分析入手，以核心业务对象传递为基础，梳理识别流程片段，将流程服务转变为子流程和服务组合。流程服务的识别需要考虑服务的粒度，应以识别出来的流程片段本身也具备一定的服务价值为重要的衡量标准。

方法论：如何从0到1搭建一套完整的邀请体系

Wed, 02 Dec 2020 00:13:29 CST

最近对邀请好友做任务类的产品功能思考还是挺多的，有一些思考分享给大家。

写文章前，把网上的邀请好友类文章，刷了大半，有很多都挺不错：有深度、有案例、有数据、有实操建议，贴部分好文如下：

大部分文章都基本会落脚在： 邀请功能的某个点或者整条线上，比较易读，也有冲击力。但我较少看到：体系化的文章（或许我没看到）。

今天笔者试着来写一写： 如何从0到1搭建一套完整的邀请体系。笔者才疏学浅，仅是一个角度思考，欢迎一起探讨成长！

老规矩，文中邀请体系的流程图/框架图都整理表格 ， 需要的关注公众号 ： 大雄背起行囊 回复【邀请】 即可获取 。

在构建邀请体系时，笔者以如下3个问题反思它的价值：

1、这套方法论，是不是一种可迁移的能力？不管是哪个行业、哪个产品阶段都能使用。

2、这个邀请框架，从满足业务诉求上，是不是延展性强、复用性高？

3、这种组件化的设计理念，是不是可以快速适配80%以上的邀请需求？

如果，以上问题都有肯定的答案，那么它的目的就达到了。

00 本文框架概览

1. 为何要做邀请功能？

2.系统化的邀请体系该如何设计？

2.1 搞懂宏观：邀请流程视图及底层架构

2.2 发力微观：做个有灵魂的产品

2.3 设计组件化：四两拨千斤的能力

3. 邀请能力升级：数据驱动产品迭代

01 为何要做邀请功能？

万事万物皆有因果。做之前，搞清楚为什么做，往往更为关键。

你可能会说：竞品做了一个邀请功能超级好，带来了很多增长，我们也做一个试试；

或者老板说：最近我们产品的用户增长遇到了瓶颈，需要用老带新的方式，提供新的增长点。都可以的，搞清楚目标及定位就ok。

笔者认为：邀请功能持续被大家推崇，有两个大原因

1、流量红利消失带来的焦虑感。付费型流量贵、质量不可控；私域流量不一定具有普适性、也未必玩得转；

2、邀请功能作为其中一个流量抓手，免费、可控、有背书，自带BMG式的出场让大家满怀期待。

当然，从大方向上的达成一致，并不意味着条件成熟。是否真的、需要立马采取行动？不妨用下面的三个问题check下。

1、当前产品所处的是什么阶段？种子期、成长期、稳定期、衰退期

2、当前产品遇到了什么问题？增长乏力、留存低、复购差

3、解决产品当前的问题只有邀请这一种？

如果你都想清楚了，那就开始行动吧！

02 系统化的邀请体系该如何设计？

邀请好友功能，一般说成MGM（member get member），会员拉会员，即为常说的老（M1）带新（M2）。根据开篇说的三个问题，体系化的邀请功能该如何思考及落地？

先附上整个规划框架

2.1 搞懂宏观：邀请流程视图及底层架构

邀请流程视图

从用户来角度，邀请功能有一套完整的、标准的流程视图：M1先做什么？M2后做什么？最终他们获得什么？。见下图：

共7步，每一步都有对应的要点及交付物，这样也就方便需求方快速地提交需求并及时响应。具体找2个节点描述下（完整的内容，可联系笔者）

step2：业务交付内容

MGM作为平台的能力，需要适配不同业务方的需求，比如平台运营，需要拉新、拉回流；某一块业务，需求就偏向于拉业务的销量。

此表的作用有两个：

1是：充分调研业务的需求，因为作为设计者，你不可能完全了解业务；

2是：管理业务的需求，按照业务的迫切程度，排出优先级及管理预期。

step4：M1邀请页

这个页面非常关键，也是决定分享率的重要因素。在设计的过程中，既要考虑页面框架的通用性，也要考虑特殊业务场景的需求。但M1的邀请页设计的核心是不变的：把握M1的需求，给予他们一个充分的动机，并降低他的完成成本。即为：需求--动机--能力

MGM底层架构

上面说了MGM的用户视角规范流程，但仅有前端的规范是远远不够的。产品经理需要抽象出邀请功能的系统能力，以对接上前端应用。见下图，分4大模块；数据、系统能力、运营配置以及前端应用。一个MGM需求要快速上线、功能要高可用，就要重点打磨两个方面：

1、MGM的组件能力：邀请组件能够快速在业务场景、活动页面配置并上线。

2、中台能力：达标工厂：简单的业务不需要中台，如果是一个金融类的产品，就有非常多的达标条件，需要将各类条件抽象出来，集合成业务中台，实现各类业务快速组装、配置、调用的诉求。

2.2 发力微观：做个有灵魂的产品

有了整体的框架，还不够，还需要从细节处着手，从微观层面发力。在邀请类功能里，什么是微观？微观是：产品界面的信息结构如何布局，交互细节如何设计。

M1邀请页面、M2参与页，并不是简单的信息堆砌，它是有灵魂的，遵循一定的设计逻辑的，笔者称之为：加工流水线。

较多的启发也来自于，何杨老师写的《产品文案如何写，才能高效表达产品卖点》一文中的精髓：池子法则。图示如下：A代表动机，B代表能力。有了持续、稳定的输入，才有更优质的输出。

利益池：枚举邀请页面的利益点，挑选、提炼重点几条对M1触动最大的利益点。

动机池：包含行动目的，以及采取行动所需付出的成本。

成品池：对关键元素进行加工，利益点&动机&能力，排优先级并逐一陈列。

具体怎么应用：以瑞幸咖啡的M1邀请页面来举例

利益池：

1）奖励一杯咖啡

2）好友免费喝一杯

动机池：

1）动机：现在我想免费喝

2）能力：分享一下就好了，很简单

成品池：

品牌主图+利益点（易记忆）、采取行动（分享）、查询奖励（关注点）、活动规则（收起）

概括：页面结构清晰、利益点突出、参与流程直接。整体设计丝毫不拖泥带水。

2.3 设计组件化：四两拨千斤的能力

这一部分，交互视觉的同学是大有可为的模块。目标就是：通过设计模块组件化，能够像乐高积木一样，快速搭建出一个MGM活动页面。组件可复制、可延展。这样一来，就可以快速支持业务需求。

笔者认为可以抽象的组件有：

1、MGM入口场景的设计图

2、页面主图的利益点排布规范：花钱的、不花钱的

3、奖励内容设计：花钱的：定额奖励/阶梯奖励/惊喜奖励；不花钱的：情感化分享卡片

4、邀请流程模块：流程事项123

5、活动规则：展示形式，页面平铺还是弹窗

03 邀请能力升级：数据驱动产品迭代

一个有价值的产品，一定是能接受住考验的。而数据，就是其最好的证明。因此，笔者愿意将数据部分单独来讲，反思下从开篇我们说的：3个问题。

1、方法论是否能迁移

就要监测这一套系统的方法论，能否适配各类业务、各种行业。大家不妨放到各种业务场景下，检验它的可用性。

2、框架是否高可用

1）是否支持各类业务达标要求，反观达标工厂的颗粒度支持情况

2）邀请活动的效果：M1分享率、M2达标率，两者所对应出来的指标，如果过低，就要从两个纬度思考：未分享前：突出利益点，分享后：增加流程管控：触达能力（未达标提醒、活动快结束提醒）、常态的参与入口

3、设计组件能否支持80%以上的需求

每来一个活动，请反思现有的设计组件，能否满足，是否需要重新设计？

以上就是本次要分享的内容。我们来小结下：

1、首先想清楚为什么要做邀请功能，不能病急乱投医

2、构建邀请体系：既要有宏观视野，又要从微观发力，以设计组件实现四两拨千斤

3、以数据监测不断驱动产品迭代升级

送大家一句话：切勿夜里想千路，明日走老路，想清楚就行动吧！

如果你想找笔者深入聊聊，欢迎到我公众号： 大雄背起行囊 来做客。

作者：大雄。微信公众号：大雄背起行囊。金融产品经理，有多款千万级产品设计运营经验，专注分享实战方法。

数据分析的 5 种细分方法

Sat, 31 Oct 2020 00:00:00 CST

你好，我是林骥。

在数据分析工作中，细分思维的重要性，我认为再怎么强调都不为过。

然而，很多人可能会采取一些「偷懒」的做法，浅尝辄止，不去寻找合适的细分方法，导致没有得出更有价值的分析结论。

下面我们通过一些示例，介绍 5 种常见的细分方法。

1. 按时间细分

时间可以细分为不同的跨度，包括年、月、周、日、时、分、秒等等，不同的时间跨度，数据表现可能大不相同。

比如说，按照月度来看，产品的销量可能变化不大，但是如果细分到每一天，可能就有比较剧烈的变化，我们应该找到这些变化的数据，并分析变化背后的原因，而不是让它淹没在整月汇总数据的表象之中。

2. 按空间细分

空间主要是指按地域进行划分，包括世界、洲、国家、省份、城市、区等等。

比如说，把全国的 GDP 数据，细分到每一个省份。

空间作为一个相对抽象的概念，也可以代表其他与业务相关的各种事物，比如产品、人员、类别等等，只要有助于理解事物的本质，都可以尝试拿来进行细分。

3. 按过程细分

把业务细分为一些具体的过程，往往能够让复杂的问题简单化。

比如说，把订单发货细分为 5 个过程，想办法提升每个过程的效率，从而缩短发货的时间。

再比如，把用户的生命周期，细分为 5 个重要的过程，即：获取、激活、留存、盈利、推荐。

4. 按公式细分

有时候一个指标，是可以用公式计算出来的。

比如说，销售额 = 销售数量 * 平均单价，销售数量 = 新客户购买数量 + 老客户购买数量，以此类推。

再比如，在财务分析中，权益净利率 = 资产净利率 * 权益乘数，其中：资产净利率 = 销售净利率 * 资产周转率，以此类推。

5. 按模型细分

数据分析的模型有很多，我们可以根据业务的实际情况，选择合适的模型，在此基础上进行细分，得出相应的分析结论。

比如说，按照波士顿矩阵，把企业产品细分为「市场占有率」和「销售增长率」两个维度，然后画一个四象限矩阵图，其中每个象限就代表一类产品，即：明星产品、金牛产品、瘦狗产品和问题产品，对每一类产品，分别建议采取不同的发展策略。

再比如，按照 RFM 模型，把客户按三个维度进行细分，即：最近一次消费时间间隔（Recency）、消费频率（Frequency）和消费金额（Monetary），从而得到 8 种客户类别，从而有针对性地采取不同的营销策略。

小结

数据分析的目的，是为了解决问题、创造价值，不是为了分析而分析。

在运用细分思维解决问题的过程中，要做到有的放矢，围绕数据分析的目标，找到合适的方法，不要像无头苍蝇一样乱撞，更不要「偷懒」，当发现数据异常时，要多问几个为什么，尝试从不同的维度进行细分，这样既能锻炼你的数据分析思维，又能加深你对业务的理解。

上面介绍的 5 种细分方法，即：按时间细分、按空间细分、按过程细分、按公式细分和按模型细分，希望能够对你有所启发，建议你在实际工作中加以灵活运用。

长按下方的二维码，关注林骥的公众号，更多干货早知道。

欢迎加入我的免费知识星球，我每天都会在星球内分享读书笔记和思考感悟，点击左下角的阅读原文即可加入。

IT瘾方法推荐

数据库迁移的一种方法

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库 - 即刻App

提高大脑效率的7个方法

提升接口性能的39个方法，两万字总结，太全了！

theme: cyanosis

1. 优化前端接口

1.1 核心数据和非核心数据拆分为多个接口

1.2 前端并行调用多个接口

1.3 使用MD5加密，防篡改数据，减少重复校验

1.4 同步写接口改为异步写接口

1.5 页面静态化

1.6 不变资源访问CDN

2. 调用链路优化

2.1 减少跨地域调用

2.2 单元化架构：不同的用户路由到不同的集群单元

2.3 微服务拆分过细会导致Rpc调用较多

2.4 去掉中间商，减少Rpc调用

2.5 提供Client工具方法处理，而非Rpc调用

2.6 单条调用改为批量调用

2.7 并行调用

2.8 提前过滤，减少无效调用

2.9 拆分接口

3. 选择合适的存储系统

3.1 MySQL 换 Redis

3.1.1 选择合适的缓存结构

3.1.2 选择合适的缓存策略

3.2 Redis 换 本地缓存

3.3 Redis 换 Memcached

3.4 MySQL 换 ElasticSearch

3.5 MySQL 换 HBase

4.代码层次优化

4.1 同步转异步

4.2 减少日志打印

4.3 使用白名单打印日志

4.4 避免一次性查询过多数据

4.5 避免深度分页

4.6 只访问需要用到的数据

4.7 预热低流量接口

5. 数据库优化

5.1 读写分离

5.2 索引优化

5.2.1查询更新务必命中索引

5.2.2 常见索引失效的场景

5.2.3 提高索引利用率

5.3 事务和锁优化

5.4 分库分表，降低单表规模

5.5 冗余数据，提高查询性能

5.6 归档历史数据，降低单表规模

5.7 使用更强的物理机 CPU/内存/SSD硬盘

innodb_buffer_pool_size

max_connections

innodb_flush_log_at_trx_commit

innodb_thread_concurrency

innodb_read_io_threads

innodb_io_capacity

6. 压缩数据

6.1 压缩数据库和缓存数据

7. 系统优化

7.1 优化GC

7.2 提升服务器硬件

8. 交互优化

8.1 调整交互顺序

8.2 限制用户行为

贝叶斯主义投资高手的方法，可以总结为三类

一、同一件事的多个概率

二、三门问题与贝叶斯算法

三、贝叶斯计算的图形界面

四、直到有操作意义的概率

五、投资中的概率

六、三类贝叶斯主义的投资高手

七、结尾

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

一、Load分析：

情况1：CPU高、Load高

情况2：CPU低、Load高

二、CPU高、Load高情况分析

2.1、使用 vmstat 查看系统纬度的 CPU 负载

2.1、使用 top 查看进程纬度的 CPU 负载

2.2、strace命令分析

3.2 Redis 换本地缓存