IT瘾经验推荐

OpenClaw分享

Sun, 15 Mar 2026 14:45:28 CST

以下PPT和内容，来源是我跟一群爱学习的朋友一起学时下大火的OpenClaw小龙虾，我给大家做了个小分享。

PPT几乎是OpenClaw输出的内容，下面的会议总结也是GPT根据会议录屏总结的。

需要注意的是，我其实没有将小龙虾玩得很深，因为我从心底里是不信任AI的，也就不敢给它太多权限。所以内容也都比较浅，请见谅。

OpenClaw 会议总结

这次分享的核心，不是在介绍一个“聊天机器人”，而是在介绍一套可自托管、可扩展、可执行任务的 个人 AI 基础设施。分享者把 OpenClaw 定位为“装进手机里的 AI 助手”：用户通过 WhatsApp、Telegram 等聊天入口发出请求，背后由部署在自己电脑或服务器上的 OpenClaw 网关完成会话管理、记忆注入、工具调用和本地执行，再把结果返回到聊天端。PPT 对这一定位和整体链路描述得很清楚。

一、这场分享的主线是什么

整场分享围绕一个很明确的问题展开： 为什么需要 OpenClaw，而不是直接用通用聊天产品。

PPT 给出的答案是，ChatGPT 更像“顾问”，而 OpenClaw 更像“助手”——它不是只回答问题，而是要具备持续记忆、调用工具、执行动作、主动提醒和接入个人环境的能力。具体包括：

有长期记忆，不是每次会话都“重新认识你”
能直接操作文件、终端、日历等外部系统
可以通过心跳机制和定时任务主动触达用户
以自托管方式运行，强调自主可控和隐私优先
按用量计费，面向愿意折腾和深度定制的用户群体

从表达方式上看，这不是一场“功能堆砌式”介绍，而是在尝试说明： OpenClaw 的价值不在模型本身，而在模型外层那一整套长期运行的个人代理系统。

二、OpenClaw 的核心能力框架

根据 PPT，OpenClaw 的能力可以概括成四层：

1. 聊天入口层

支持 WhatsApp、Telegram、iMessage、Discord、Slack 等多个消息平台，目标是让用户沿用已有通信习惯，而不必专门切换到某个 AI 产品界面。PPT 明确强调：“换了聊天软件，AI 还是同一个——记忆和设置全部保留。”

2. 网关与调度层

消息进入后，由 OpenClaw 网关完成身份验证、会话管理、消息路由、工具执行和记忆注入。PPT 用“一条消息的旅程”说明了从手机发消息，到加载 USER.md / MEMORY.md，再到发给模型、决策调用工具、执行、最后自然语言回复的完整链路。

3. 记忆与人格层

这是分享里非常重要的一部分。PPT 把记忆系统拆成多个 Markdown 文件：

SOUL.md：AI 的人格、风格、语气
USER.md：用户身份、背景、偏好
MEMORY.md：长期累积的重要记忆
AGENTS.md：规则、权限边界与行为约束

这种设计的意义在于：AI 的“性格、知识、权限和历史”都变成了用户可编辑的文本资产，而不是封装在黑箱里。

4. 工具与执行层

PPT 列出的工具包括文件读写、shell 执行、浏览器控制、网页搜索、手机节点、canvas、tts、消息推送等，目标是让 AI 能从“回答”升级为“完成任务”。同时也强调了工具级权限控制、白名单验证、分场景配置以及 Docker 隔离等安全措施。

三、这次录屏里真正有说服力的部分：不是讲概念，而是做了演示

结合录屏画面看，分享并没有停留在 PPT 层面，而是穿插了实际操作，这一点增强了可信度。

从录屏中能看到，分享后半段进入了一个类似 ClawHub 的界面，现场展示了一个 Trello Skill 的文件内容、配置说明和调用方式；随后又切到 Telegram 对话窗口，以及本地终端，演示如何通过消息端触发配置流程，并把第三方能力接到 OpenClaw 体系里。这个流程说明两件事：

Skills 不是抽象概念，而是可安装、可配置、可调用的扩展能力。
OpenClaw 的“手机端 AI 助手”并不依赖复杂前端，而是通过消息通道串起技能、工具和运行环境。

从演示节奏上看，分享者实际上是在证明：

OpenClaw 的价值不只是“能接模型”，而是能把模型、工具、个人环境、外部平台和长期记忆组合成一个持续在线的代理系统。

四、这场分享传达出的三个关键判断

1. OpenClaw 的竞争点不是模型能力，而是“代理能力”

这套系统的重点不是谁的模型更聪明，而是谁更能接入现实世界、持续服务用户、并完成闭环动作。PPT 中“帮你做，不只说”就是这个核心。

2. 它更像一个 AI 操作系统，而不是单点应用

无论是记忆文件、agent 配置、skills 插件、heartbeat、cron，还是多账号/多角色隔离，整体架构都更接近一个可编排的 AI runtime，而不是普通对话产品。尤其是“家庭共享、工作/私人分离、权限分级”这些设计，说明它从一开始就考虑了长期运营而不是一次性 demo。

3. 目标用户非常清晰：不是大众用户，而是愿意部署、愿意调教、愿意承担维护成本的人

PPT 直接写明更适合有服务器/NAS/Mac mini、喜欢定制、想要私人 AI、重视掌控权的人。这一点判断是务实的，也符合演示中的实际复杂度。

五、我认为这场分享里最值得保留的亮点

最亮的点有三个：

一是记忆系统设计。

用普通 Markdown 管理 persona、user profile、memory、agent rule，这个思路非常工程化，也非常利于用户理解和修改。

二是主动性机制。

PPT 提到 heartbeat 每 30 分钟自动唤醒、检查邮件/日历/待办，并通过 cron 做天气摘要、周报提醒、服务器状态检查。这意味着 AI 不再只在被提问时才工作，而是能持续担任“个人运维助手”。

三是多智能体与权限隔离。

同一套网关下，可以给自己、家人、工作场景分别配置不同 Agent，并限制工具权限。这使它具备了现实部署价值，而不是仅适合个人极客实验。

六、这场分享也有意保留了几个“没有过度包装”的点

这一点我觉得反而很专业。

PPT 里并没有把 OpenClaw 完全神化，而是明确写出了几个边界条件：

文件和命令虽然在本地处理，但 部分内容仍会发送到 token provider，因此“隐私优先”不是绝对封闭
为了达到较好效果，上下文很长， 按量付费未必便宜
Docker 隔离是建议配置，不是默认配置
在“重视隐私的人”这一页里，演讲者自己还留了保留意见，说明他并不是无条件认可全部宣传口径

这些细节说明，分享者对产品定位是偏清醒的：

OpenClaw 很强，但它不是零成本、零配置、零风险的万能方案。

七、结论

如果要用一句更专业的话来概括，这次分享展示的是：

OpenClaw 不是一个 AI 聊天应用，而是一套面向个人场景的、自托管 AI Agent 基础设施。它通过消息入口、长期记忆、工具调用、任务调度和多代理隔离，把大模型从“会回答”推进到“能持续协助与执行”。

The post OpenClaw分享 first appeared on I am LAZY bones?.

拼多多20条运营小技巧

Wed, 24 Dec 2025 11:28:46 CST

拼多多的运营看似粗放，实则细节决定生死。本文提炼20条实战技巧，从高转化定价、层级突破到截流应对与付费策略，直击平台算法偏好与流量逻辑，帮助商家在强付费竞争中精准提效、稳住ROI。

最近开始接触某东某宝等其他电商平台，做下来后发现，各个电商平台的底层逻辑倒是一样的，都是付费买流量。

现在每个平台都有所谓的全站推广，也就是咱们卖家开车推广只需要设置一个目标投产比，剩下的让平台跑单量就可以了。

道理虽然都是这个道理，但跑下来的效果就各有千秋了。这也是各个平台之间不同技术和规则导致的，就跟每个炒菜馆都有西红柿炒鸡蛋这道菜，但每家的做法和味道都各有各的特点。

本文，咱就来讲讲我主做的拼多多这个电商平台的20条运营小技巧，毕竟不同平台不同的规则，拼多多平台的运营技巧，还是得单独看。

高转化率=快速起量

众所周知拼多多起量就是快，快的2天干到1000单都是常事。那么问题来了，咱们如何能干到2天1000单呢？答案是：能不能做到，不是看你的能力，而是看资源。

平台的算法是高转化率的链接会持续推流，那么什么样的链接转化率会很高呢？主图详情牛掰的？基础数据特别高的？SKU布局很到位的？这些都不是，告诉大家，价格到位了，转化率是最高的！其他的大家细品就好，尤其是大标品表现最为突出。

层级决定流量上限

已经上了3层级的店铺，对流量的感知不是很明显。但是刚起店时1层级和2层级店铺的流量上限就会很明显。除非卖价有优势可以打破流量天花板，其他常规品在1层级的话，每天单量只能在个位数，要强车硬拉，先把店铺拉到2层级，这样店铺会好做一点点。

店铺星级比消费者体验指标更重要

经常有新人问我消费者体验分怎么去拉，我一看问的是消费者体验分，直接回复，这个就当没看见。

拼多多最看重的是店铺星级，4颗星5颗星那个，如果店铺星级低于4.5颗星，就会影响到流量，低于4.3颗星就上不了活动了，低于4颗星，店铺就别要了。至于消费者体验分，高了低了，只要不是很离谱的数据就没啥影响。

每日必做商品体检

有次我一个链接莫名断流了，评分、价格、直通车都没啥问题，于是推测是不是被截流了。然而第二天进行商品体检时，那个断流的链接直接提示为SKU图片违规。

图片违规这东西自己排查可是排查不出来的，于是把图一换，流量又起来了，对于显性的流量降权等问题，是可以用商品体检排查出来的。

超时发货=虚假发货

再提醒各位拼多多新人，发货一定不要超时，不能做到24小时发货的，千万别勾选24小时发货。只要超时发货，系统就判定为虚假发货，且申诉无效。虚假发货的处罚不仅仅是扣几块钱，最主要是店铺降权，如果出现批量虚假发货，店铺也别要了。

有活动好过没活动

拼多多最好的玩法一定是活动配车，其次是仅开车或者仅活动。对于一个普通链接，在活动位上不仅仅有流量扶持，更重要是有活动标，有标和没标转化率能相差个10%。

但是问题又来了，大标品上活动，哪怕是大促活动，系统建议价都给的很低，很难报，这个就看大家的资源有没有优势了。另外白牌产品，这个嘛，有没有活动都那样！

ROI比成交出价更稳定

直通车有成交出价和投产比出价，之前我玩多支SKU特别喜欢用成交出价，这样跑下来一支平，多支赚，好不快活。然而现在跑出来发现，系统更鸡贼了，如果开成交出价，系统就会拉低客单人群，只拍一支的，搞得投产比很低很低。

所以，除非统一卖价的高客单品，其他多SKU高客单以及所有低客单的品，都开投产比出价就可以了。

直通车千万别提示余额不足

大家不要以为直通车没钱了才会断流，这样说吧，只要余额不足，哪怕还剩下个几十块，系统就会给你断流了。好几次直通车明明有余额，但是曝光腰斩，把钱补多一些后，曝光又起来了，说明系统给不给曝光，就是看你兜里的玛尼够不够花的。

日限额不要上来就无限额

有些新人习惯上来就开无限额，这样操作不太好。一是万一设置错了卖价，再加上个自动充值，那遇到薅羊毛的，岂不是亏的裤衩都没了。

还有就是一上来开无限，系统默认你这个链接是有利润的，直通车就会少曝光杀价，想拿曝光就得降低投产比出价，与咱们的目标背道而驰。所以，先设置个几百的限额，等稳定出单有利润了，再开无限也不迟。

三十天不出单链接尽快下架

平台虽然没有说过考核链接动销率，但是店铺里不动销链接多了，总感觉店铺跑的会很迟钝，所以我建议是每天排查在售链接，30天不出单的链接尽快下架。如果之前有单现在没单了，发布相似品继续做。如果是新链接，说明链接不行，直接下架。

发布相似品链接可以承接流量

对于推广受限或者其他原因导致这个链接挂了的，我们前期砸这条链接的车费是不是打水漂了？是的。但是有个方法可以补救一下，就是该条链接发布相似品，一模一样的去上架，这样可以很好的承接到之前的流量，达到快速重新起链接的目的。

截流就玩机会商品

如果各位有资源有优势的品，那么就去机会商品发布商品吧，如果你的卖价能按照机会商品给的卖价来，你这个链接上架之后直通车稍微出个价就能出单，机会商品都是别人已经起量的链接和品，照着做效率高，起量快。

定价=拼单价+限时限量购

拼多多定价跟其他平台不太一样，常规的到手价设置方式就是虚高拼单价加限时限量购了。至于券之类的，那个就要具体问题具体分析了。正常情况下，限时限量购等于到手价就差不多了。当然，拼单价=到手价也不是不行，就是这样做的人少。

讲解视频必须要传

上完链接后第一件事就是把讲解视频上传上去，图文都是静态的，讲解视频是动态的，有了讲解视频链接转化率会提高一点点，且还能获得视频推荐的流量。不过同品尽量选不同的讲解视频，不然多个链接用一个讲解视频，容易被驳回。

链接断流不要慌

拼多多平台链接断流掉量是很正常的，没有哪个商家链接能稳定跑六个月以上的。我五星店铺评价90%以上的链接还动不动的断流，所以，做好随时起新链接的准备就可以了。不要寄希望于一条链接过日子，在拼多多这里不可取。

好品可以开运费险

运费险要不要开呢？答案是看情况。如果各位做的品质量可以，那就打开运费险，好品退货的概率会小很多，开了运费险等于给买家一个承诺，是可以提高转化率的。

但如果是垃圾品，就不要开运费险了，我做过50%退货退款率的品，把运费险一关就降到了30%，所以开不开运费险主要看品的品质。

起量速度=拖价节奏

直通车怎样拖价最合适，其实没有标准的。真正的标准就是根据链接的起量快慢来拖价。链接起的快，拖价就可以快。比如一天增长百单以上的，拖价可以按照投产比增加0.5的节奏来。如果一天增长10单，那么拖价只能0.2的节奏来了。拖价快慢就取决于单量增长的快慢了。

好品才能长久运营

虽说拼多多链接不稳定，但是好品的链接存活时间是要远远大于垃圾品的，我做过的某垃圾品，3天起量，7天死链接的都有。而好品，起量之后活3个月以上是有可能的。好品断流更多的是被截流导致的，应对截流就没必要起新链接，直接洗SKU就可以了。

最好的防比价就是独家品

关于活动被比价的事，是不是很让各位苦恼，那么如何做到防比价呢？答案就是这个品就你有，别人没有，这样你想多少卖价报活动，都不会被比价。

那么真的问题就来了，你有没有畅销的且只有你有别人没有的品呢？大概率是没有的。你有的只有高价白牌，这种别人是没有，但是高价白牌没销量也没意义。归根到底拼的还是资源。

常规商家主要还是玩强付费

最后一条奉劝各位对自然流抱有幻想的老板，如果你不是源头厂家，那么你只能玩强付费。付费买流量是除极个别商家外的主流玩法，大家要做的只有一件事，核算好产品的成本和保本投产比，以及想办法开出有利润的投产比就完事了。

最后

魔鬼的魅力在于细节，想把拼多多做好，不是会一两招厉害的技术玩法就可以做到的，要精益求精，各个环节要做到位。

别的不说，上面讲的20条运营小技巧都掌握了，做拼多多也会好做那么一丢丢。

本文由运营派作者【老虎讲运营】，微信公众号：【老虎讲运营】，原创/授权发布于运营派，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

5500篇新冠痊愈经验，告诉你阳了怎么办

Sat, 24 Dec 2022 17:22:58 CST

从阳过到阳康，过来人告诉你该怎么做

距离“新十条”发布已经过去两周，首批在朋友圈宣告阳性、连载病程的新冠患者也逐渐康复，喜提抗体。

对于大部分人来说，这是三年来首次直面新冠病毒的两周，从一线城市到县城乡镇，办公室、小区、校园纷纷上演“奥密克戎版狼人杀”，一睁眼身边就有人嗓子“被刀”。

这也是信息超载的两周，抗原怎么用、什么药不能同时吃、同事/家人/室友阳了怎么办，家族群里平均每天有 10 个专家出手解答。

两周以来，也有上万名网友在互联网平台参与了“新冠康复日记”的话题讨论，我们统计了其中的 5572 篇日记，提炼出常见症状、好物推荐等不同维度的排行榜。

我们希望用当下最鲜活的经验帖、抗疫经验，为正在苦战或尚未感染的你提供一些面对病毒的信心，亦或是为已经康复的你带来些许共鸣。

刀片嗓，不愿经历第二次

12 月 15 日，钟南山院士在全国高校抗疫大讲堂讲座中表示，新冠走到现在的状态实际上是“新冠上呼吸道感染”，或者甚至简单地说就是“新冠感冒” [1]。

不过，在最近很多“阳过”的分享中，感染新冠还是比普通感冒要难受，症状和流感更接近。在五千多名网友的新冠康复日记里，发烧、咳嗽和酸痛是最常见的三种新冠症状。

根据北京市卫健委发布的《新型冠状病毒阳性感染者居家康复实用手册（第一版）》，一般普通中青年患者感染新冠病毒，病程为 7 天左右，通常在第二天开始发热，第三天出现高热症状 [2]。

大多数人对于发烧都不陌生，无非是冷热交替的冰火两重天：

晚上睡觉的时候全身发冷，脸上却能煎鸡蛋。当时我真想把冰冷的脚在脸上贴贴，退烧还暖脚。

但最折磨的是遇上反复高烧，在希望和绝望之间反复横跳：

第一天：体温39，反复高烧无法降温；第二天：反复高烧，体温能降低到37左右；第三天：晚上高烧，体温能降低到36左右。第四天：退烧。在经历了N次反复高烧以后，终于恢复到了一个比较正常的状态。

除了发高烧，咳嗽也足以消磨人的精气神。在发病的不同时期，咳嗽会以干咳、咳痰等不同形式出现。“半夜被咳醒”“一呼吸就想咳嗽”“咳得肚子痛”都是常规反应。

伴随着咳嗽而来的，还有鼻塞和流涕，体验“水泥糊鼻”的窒息感：

第七天，体会到了水泥封鼻孔的感觉，鼻塞到窒息，咳嗽有痰，继续流鼻涕打喷嚏，两只眼睛流眼泪，七窍只剩下两窍还健在。

进入病程后期，不少人都出现了味觉/嗅觉在一定程度上减弱的情况。

值得一提的是，在这一时期，靠吃“火鸡面”“麻辣锅”来测试味蕾是无效的，“辣是痛觉”这个知识点，不必等到辣得面目狰狞、嘴里还只有苦味的时候才明白。

在一众新冠症状里，要说最出圈、最让人望而生畏的，当属被冠以“刀片过喉”“宝娟嗓”之名的上呼吸道疼痛。

为什么感染后咽口水像吞刀片？

北京地坛医院急诊主任王凌航曾在采访中解释，这主要是因为声门和声带周围的黏膜发生了充血水肿，一般病程 3-5 天时表现明显。等呼吸道病毒感染急性期结束，病毒被清除，炎症减轻，水肿消失、改善，嗓音可以恢复 [3]。

除了嗓子，新冠病毒还对全身多个部位进行了疼痛攻击。头疼、肌肉酸痛、腰背疼、关节疼……从头到脚，病毒无所不在。

有人说，这个病毒就像是身体探测器，把平时有问题的地方放大。“比如我之前偏头痛，病程最难受就是头疼，现在其他也不疼了，可耳朵后胆经穴位跳着疼。”

阳了之后，居家如何应对

尽管当前的奥密克戎病毒已经很难击溃人的免疫防线，但面对一段未知的斗争，我们难免恐惧焦虑——怎样算高风险人群？怎么对症治疗？应该在家还是去医院？“复阳”和“二次感染”有什么区别？

可以说，掌握了这五个问题的答案，你就拥有了直视“两道杠”的勇气。

在用药方面，普遍的共识是，比起备药，更重要的是如何科学吃药。

布洛芬不仅是“痛经杀手”，也是退热利器，和对乙酰氨基酚一样，都能通过抑制下丘脑的体温调节中枢从而起到退烧效果，区别在于起效时间和作用持续时间 [4]。

需要注意的是，如果同时服用对乙酰氨基酚和布洛芬很可能超量，甚至导致急性肝衰竭，因此不建议擅自同时使用这两种药品。

而市面上常见的复方感冒药（如白加黑、泰诺等）同样含有对乙酰氨基酚成分，也不能和退烧药同时服用 [2]。

发烧是人体对外界各种致病因素的防御反应，是我们的免疫系统积极和病原体战斗的表现，因此，一般认为体温低于 38.5℃ 时，不需要使用退烧药。

但 38.5℃ 这个分界点其实并不那么严格，遇到身体明显不适时，也可以按照说明书适当服用 [5]。

症状明显好转之后，根据官方指南，需要满足自测抗原阴性、且连续两次间隔超过 24 小时的核酸阴性后方可解除居家治疗，不过实际上很多地方要求并不严格，符合抗原阴性就能返岗。

此外，在新冠康复后，虽然免疫功能正常的人群发生“复阳”和“二次感染”的概率都很低，但一个人确实有可能因毒株不同而发生多次感染，因此戴口罩、勤消毒等基本的防护还是不能落下 [6]。

在新冠康复日记里，除了“怎么治”，网友们还关心应该“怎么吃”。

曾经把奶茶咖啡当水喝的年轻人，如今全靠自制电解质水、雪梨水、苹果热橙茶续命：

发烧：每一升温水，加 3g 盐、一勺麦卢卡蜂蜜以及一片柠檬的配比，就可以得到一份自制电解质水。是的，就是这么简单。干咳：冰糖炖生梨，可以加百合、杏仁粉、金银花。

新冠感染期间，发烧出汗会让身体大量脱水，电解质水能够快速解决电解质失衡的问题，帮助身体维持正常的功能。不过，如果能正常饮食，一般也不需要额外补充 [7]。

至于最近走红的“盐蒸橙子”，确实可以补充水分、盐分，提振食欲，当然也可以用其他水果来替代。

1.把橙子洗干净 2.橙子头切开、撒盐 3.把盐均匀的用叉子或者筷子戳进去 4.盖上橙子盖子蒸 20 分钟左右。一开始会觉得有点奇怪，为什么要撒盐。后来发现酸酸甜甜加点盐，有点海盐橙汁的感觉。不过记得要把盐均匀地戳在橙子里面，不然味道会很奇怪。

面对“小刀剌嗓子”的普遍症状，除了吃西红柿拌白糖和水果罐头，喉糖也能派上用场。

在“新冠”“喉糖推荐”的关键词限定下，日本龙角散以断层优势高居榜首。

网友最推荐的十款喉糖既包括金嗓子喉片、桂林西瓜霜含片这种老牌国民产品，也包含使立消、利口乐等国外品牌。

新冠康复，离不开靠谱的队友

五千多篇新冠康复日记，不仅记录了人们对抗病毒的客观进程，也书写了后疫情时代的情感记忆。这些被共同记录的人和事，也是新冠康复过程的重要组成部分。

日记里，被提及最多的群体是孩子、朋友和医生。尽管与成人相比，儿童感染奥密克戎后症状更轻、病程更短，但对于不少新手爸妈来说，如何熬过孩子的病期始终是个巨大的挑战 [8]。

一段持续一周的病情，也成为人际关系的试金石。有人发现了“生活不能自理”的室友的另一面：

在我阳了之后，我的室友撑起了这个家，消毒做饭帮我收拾东西烫药一条龙服务，原来还以为她是个生活残障人士，关键时刻这么靠谱。

有人得到了领导充满人性的回复（不排除是被领导关注了社交平台）：

中午时分和领导汇报情况，领导的嘱咐依旧是好好休息，养好了再去上班，在此感谢我亲爱的领导和辛苦的同事。

孕妇、老人等特殊人群也得到了较多的关注。不少准妈妈现身说法，“给同在孕期的姐妹阳了之后总结一些经验”。

也有人不断呼吁关注信息相对闭塞的老年人，教会他们使用抗原、关注他们的药量储备情况，作为无基础病的年轻人，能居家治疗就少去医院，把医疗资源留给更需要的人群。

除了牵挂的人，日记里还有一些特殊的关键词，勾连着新冠康复过程中的难忘经历。

最常见的经历，和抗原有关。买不到、测不准的抗原，总能激起人最大程度的焦虑，甚至患上“幻阳症”：

我现在咳嗽两声，流点鼻涕，就老疑神疑鬼觉得自己中招了，抗原用了好几盒，一直都是一道杠。可能哪天真阳了，会松口气觉得另一只靴子终于落地了吧。

还有些经历，和奥密克戎的“通情达理”有关，“一般一家五口人会得病四个，留下一个买菜做饭”：

全家唯一一个暂时幸免的饲养员，全天戴着口罩忙活了一天，买菜、做饭、投喂病号，熬梨汤，督促每个人喝水，扫地，擦地，全屋消毒，辅导功课，上传作业，还得加班写 PPT，忙得不亦乐乎。喝了 2 大杯维 C 泡腾水，但嗓子还是略疼略干，浑身也有酸疼的症状了，不知道我这金刚不坏之身还能挺多久。

对于考研学生来说，“有时候，你永远不知道研究生通知书和新冠病毒哪一个先来”，如果再撞上经期，就可以叠满“上岸 buff”:

从知道自己阳了的时候，就感觉今年考研难度又上升了，好巧不巧的是来姨妈了，真是祸不单行，心想要是扛过去了，今年考试一定能上岸吧。

在所有涉及情绪的关键词里，“恐惧”“焦虑”被提及的次数最多，但几乎所有人都会在后面跟上一句相似的安慰——“积极面对，一切都会好起来”。

有资深执业心理咨询师表示，人们的恐惧来源于失序，这是一种自我保护机制，而打破内心恐惧是一种必然经历 [9]。多听听身边人分享亲身经历，能够帮助人们在心理上重建秩序，减少对病毒的恐惧。

随着越来越多人从新冠中康复，“成为阳性”无需有病耻感，我们需要专业的救助，也需要普通人之间的守望互助，最后我们必须承认，无知和孤立远比病毒本身更可怕。

本文科学性已由女王大学病理及分子医学硕士伍丽青审核

作者：起司黄

数据：平凡の维

设计：杨波浪敏穗

参考文献

[1] 高佳. (2022). 钟南山：奥密克戎感染不再适合称为新冠肺炎，病毒不存在“北强南弱”. 界面新闻. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/l60AhwnAnfwfoo5Mx-VNCQ.

[2] 北京日报. (2022). 感染者居家康复实用手册【官方版】. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/R3NNRqQ0LQ5Ec12LhMd8Dw.

[3] 中国新闻网. (2022). “吞刀片”“宝鹃嗓”如何快速缓解？吃冷饮有用吗？. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/J0QiTycaDyJGSaFIBUA1WQ.

[4] 王伟立. (2022). 布洛芬与对乙酰氨基酚治疗呼吸系统感染发热患者的疗效对比. 大医生,第7卷,(9), 35-37.

[5] 李秀婷. (2022). 关于退烧，一文看懂！这些退烧药不推荐使用. 南方网. Retrieved 22 December 2022 from https://news.southcn.com/node_d9f3d1280b/8ed4fd5e85.shtml.

[6] 央视新闻. (2022). 如何区分“复阳”和“二次感染”？专家解读. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/CPpx3tta321RrwIViF4uzA

[7] 光明网. (2022).盐蒸橙子、葱白烧水，“新冠民间偏方”科学性如何？. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/6Sw8BsAK9e2VwPJSnFIR1Q.

[8] 杨菲菲. (2022). 孩子“阳”了怎么办？知名医师给家长支招. 新京报. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/Gz6RuQ8HyCP-70_TtvjD4g.

[9] 高伊琛. (2022). 他们“阳”了，为什么要晒朋友圈？. 南方周末. Retrieved 22 December 2022 from https://mp.weixin.qq.com/s/ysTHsT09Ce5ATPxtVOkhqQ.

短视频运营该如何考核？

Wed, 12 Oct 2022 17:34:29 CST

近年来，短视频行业不断崛起，不少企业都纷纷入局短视频行业。但对于该行业的岗位管理，许多企业仍然不知道如何运营管理，制定相应的模板和结果，驱动员工自发成长，从中获取更大利益。那么短视频运营的绩效应该如何制定？

近年来短视频行业快速崛起，市场规模持续扩大，加之疫情“宅家”的要求，间接加速了短视频用户规模的强势增长。

据统计，我国短视频用户规模由2016年的1.9亿人增长至2021年8.97亿人。以当下最火热的两个平台举例：视频号月活用户达到8亿，抖音月活用户达到6.8亿。

在这样的行业背景下，越来越多的企业和个人都开设起短视频账号，想要从中获取流量红利。

而对许多传统企业的老板而言，他们根本不懂短视频，也不知道如何运营管理，如何制定合理有效的考核标准，最后的结果差强人意。

所以绩效考核对于企业管理的重要性不言而喻，有效制定目标和结果，可以驱动员工自我成长，实现企业和员工的双赢。

那么短视频运营的绩效应该如何制定？

01 短视频运营的工作内容

首先要界定公司里短视频运营的工作内容是什么，确定岗位职责后再制定具体的绩效考核内容。

通常一个完整的短视频团队架构包括：编导、摄像、剪辑、演员、运营等。但大部分企业的短视频团队并不成熟，很多时候需要一人身兼多职，尤其对运营岗位提出了更高的要求。

boss直聘某企业短视频运营要求

短视频运营，需要负责以下核心的工作内容：

1）内容产出。负责内容的选题、脚本的撰写、视频的拍摄、后期剪辑、道具准备等；

2）账号维护。负责账号的定位、日常运营维护、广告投放等；

3）粉丝运营。对粉丝量、评论数、意向用户等指标负责；

4）数据复盘。能够对播放量、点赞量、分享量等视频数据进行分析优化。

当然，最终企业要招多少人，招什么样的人，要取决于企业本身的业务需求和目标来决定。

每家短视频公司对绩效考核的理解都不同，但关键在于不能为了考核而考核。下面说说具体如何来制定考核标准。

02 绩效考核如何制定？

每个账号在不同阶段，考核重点也不一样，例如：

账号刚起步1-3个月属于孵化期，应该重点关注视频的更新数量、播放量；
3-6个月属于账号的运营期，应该重点关注粉丝增长量；
6个月以上属于变现期，多关注直播的数据；

运营的薪资结构建议比例是：70%底薪+30%绩效，再把绩效分为两部分：

KPI（可以衡量的，业绩数据），占比80%。
KCI（不可衡量的，工作态度），占比20%。

做到既看结果，也看过程。

可衡量的关键绩效指标KPI，主要包括以下内容（仅供参考，实际根据账号体量来定）：

1）制作视频数量

按照视频发布的数量进行打分，例如：数量≥10条，100分；数量≥5条<10条，80分；数量<5条，30分。

2）视频作品数据

播放量：总播放量≥300万；要求至少有3条播放量破10万；达到以上任意1条，100分；低于任意1条，80分
点赞数：点赞总量高于10万；至少3条点赞量破1万；达到以上任意1条，100分；低于任意1条，80分
分享数：总分享量≥1万，100分；总分享量<1万，80分

3）账号用户量

粉丝量：粉丝净增长量≥10万，100分；粉丝净增长量<10万，80分
评价数：意向评价数≥100条，100分；意向评价数<100条，80分
私信数：向咨询用户≥50条，100分；意向咨询用户<50条，80分
官网链接（蓝V账号）：表单有效报名信息≥50条，100分；表单有效报名信息<50条，80分

不可衡量的关键胜任能力指标KCI，主要包括以下内容：

1）工作态度（上级主观评价）

一般包括：

基本素质：处理问题能力；沟通能力；执行力

日常纪律：出勤；提交日报、周报、月报

2）部门贡献

总结输出、培训、提供可执行方案等

03 绩效考核的注意事项

1. 什么时候考核变现？

变现是每个企业老板最关心的问题，也是企业做账号的最终目的，但是如果过早的去追求变现，是难的，变现的前提条件是：有一定的粉丝量；粉丝粘性高；

如果均不具备，请一定要花时间精力是做好内容，内容是本质。垂直类账号建议粉丝量在5万以上，非垂直类账号建议粉丝量在10万以上（仅供参考）。

2. 考核要注重奖罚分明

员工的绩效考核指标抓取不准、量化程度低、没有明确的评分标准和数据来源，导致次月初绩效考评的时候上级主观凭评分多。

公司花了大量精力和时间得到的结果就是大家绩效考核分“都很好”，流于形式，没有奖罚，大家不重视，导致恶性循环。

3. 制定合理工资标准

通常短视频运营，尤其和直播或变现挂钩，工资都会有较大的浮动。所以在和员工签订合同时，要制定合理的工资标准，避免后期产生纠纷。

4. 绩效没有过程检查与辅导

有些企业没有对绩效指标建立跟进与辅导机制，到月底的时候才把考核表拿出来评分，那个时候没有完成的也来不及完成了。

有的过程数据没有记录下来，导致月底的时候自己都忘记了考核数据的实际情况，就凭印象打个分。

绩效考核的目的是促进公司、部门、岗位的目标的达成，绝对不是为了绩效考核而考核。

作者：晏涛三寿；微信公众号：晏涛三寿；

本文由@晏涛三寿原创发布于运营派，未经作者许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

4步走，搭建好用的数据指标体系

Wed, 25 May 2022 10:05:32 CST

编辑导语：说起数据指标体系，大家总会想起“AARRR”、“OSM”和“UJM”等，但如果细问，你真的能说清吗？要搭建好用的数据指标体系，光有理论是不行的。这篇文章分四步讲解搭建数据指标体系的方法，一起看看吧。

一提起指标体系，很多同学像说相声一样，脱口而出“AARRR”“OSM”“UJM”……讲得好开心，可面试官多反驳一句：“我这是销售运营的指标体系！”“说清楚到底O是什么O，U是怎么U的！”就会让很多同学没了办法。

今天系统讲解下，该如何处理此类问题。和很多数据分析问题一样，OSM等理论本身没有问题。问题是不能把理论当教条，不深入业务流程之中，不考了具体场景，是没法搭建出好用的指标体系的。

一、清晰业务场景

所谓的业务场景，即：数据指标要反映的业务是啥。

它包含了四个方面：

业务方目标是什么；
业务的流程是什么；
业务方做哪些动作影响结果；
业务流程/业务流程，有啥数据记录?

很多同学面对具体业务，不知道该怎么梳理指标，本质上是对业务不熟悉。即使不问“销售运营指标体系”，而是问：

“销售卖的是啥呀？”

“销售目标客户是谁呀？”

“销售人员咋卖的呀？”

“销售运营又运营啥呀？”

一个都答不上来，那还咋梳理指标。懂业务是第一位要求，了解业务场景后，可以一步步开始梳理。

二、清晰业务目标

业务目标是业务最关心的东西，也决定了指标体系的主指标是啥。数据采集，得优先保证主指标有采集；指标体系的展开，也优先展示主指标的产生过程。

在业务方的心中，业务目标是很清晰的。因此可以直接沟通。

比如销售运营工作，常见的主指标有：

销售目标达成→指标：销售收入（金额）
销售业绩增量→指标：销售收入增长率
销售队伍稳定性→指标：整体离职率/A级离职率
特定客户开发数量→指标：整体离职率/A级离职率
……

梳理清楚这些，定下主指标，就能结合具体业务流程，看主指标是怎么实现的。

三、梳理业务流程

业务流程是主要数据来源，指标体系首要任务是反馈业务流程情况。有了主指标以后，要结合业务流程，梳理出过程指标。有了过程指标，才能解释主指标为什么低，为什么高。

还拿销售运营举例。销售运营的工作，是叠加在销售正常的工作之上的，因此有两个业务流程要梳理：

销售的操作流程
销售运营做了哪些优化

不同销售流程的操作不一样，想让指标体系具体、能落地，就得深入业务细节之中，看具体是怎么操作的。有的流程可能很简单，比如销售自带客户资源，那就自己联系客户→签约，结束。

但有的流程可能很长，比如卖软件的，从接收客户线索到成交，有N多步骤，这里是不能偷懒的，要一步步认真梳理，最好画出流程图。（如下图）

销售运营的动作，大体上可以分成三部分：

培训：培训销售们产品知识、话术、技巧
激励：物质激励、精神激励
组织：SOP制定、流程管理

这里也不能偷懒，需要了解到细节。比如培训，什么时间、什么话题、多少人参与，要了解到位。比如激励措施，物质奖励的奖励规则，要了解到细节（如下图）这些细节才是直接驱动销售干事情的动力。

这里有个常见的误区，就是很多同学在梳理指标体系的时候，只关注用户行为，不关注业务动作。比如梳理销售指标，就简单地：销售额=业务员人数*有成交比例*人均成交金额，就拉倒完事。

至于有啥奖惩措施，有啥规范制度，一概不知。这样会导致指标体系只能展示结果，不能解释原因，也没法对比分析。最后对着人数、比例、人均金额三个指标狂抓脑袋：为啥它就涨了呢？为啥它就跌了呢？（如下图）

四、确认数据采集

数据记录是保障。业务流程数字化程度不高，没有数据记录，一切免谈。比如销售运营指标体系；如果想解读销售业绩，就得掌握销售过程，得先知道销售干了啥，没干啥；如果想诊断销售能力，就得掌握销售个人画像，得先知道销售有啥经验、啥背景；如果想分析运营动作有效性，就得记录每个动作上线时间，作用在哪些人身上。

如果以上统统没有，只有一张成交订单和订单上的销售个人编号。那就真的没啥好分析的了。最后的数据就只有：销售额=业务员人数*有成交比例*人均成交金额。基于这么点可怜的数据，可以做一些简单的、粗线条的分析，比如：

对业绩排名，分析业务员业绩稳定性、找出标干
对团队排名，分析团队管理水平高低
对比活动/政策上线前后差异，粗略观察效果

当然，因为缺少细节，所以这些分析很容易被人质疑。没有数据，分析个屁！这一点一定要牢牢记在心里。

在各种场合，努力推动数字化进程，努力提高业务部门对采集数据的重视（而不是提高业务部门对数据分析成果的期望），才是数据分析师们自救法宝。

至于那种大吹特吹：“我有神威无敌大将军算法，代码一跑上知天下知地中间知空气”的主，你就跟他划清界限，让他独自面对销售的质疑，死几次他就知道改了。

作者：接地气的陈老师；来源：微信公众号“接地气学堂”

本文由@接地气的陈老师原创发布于运营派。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

如何摆脱信息茧房？

Mon, 20 Dec 2021 16:18:36 CST

编辑导语：信息茧房是指人们关注的信息领域会习惯性地被自己的兴趣所引导，从而将自己的生活桎梏于像蚕茧一般的“茧房”中的现象。现如今，人们的生活在信息茧房中，线下接触同一类圈子，线上大数据推送相类似的文章。这不是一个好的现象，如何摆脱信息茧房，如何“破圈”，本篇文章作者将告诉你答案，快来阅读吧！

“下次只能光看不点了， 我才夹一筷子，给我推送一桌子”。

早上好王先生：您的体温是38.3摄氏度，体温不正常建议去医院检查；昨天晚上您睡6个小时35分钟，当中醒来3次；其中深度睡眠时间2个小时30分钟，最近注意各项指标…….

上述声音来自我家智能管控系统和手环的反馈，好像把我生活安排的明明白白， 又窃喜又忧愁，为什么？

窃喜的是我可以 随时知道身体数据，及时调整状态；忧愁的是 “我对智能系统的依赖慢慢丧某些大脑能力”，事情只是如此简单吗？不是的。

如果我告诉你，除书和电影外， 我们的职业和人生选择都被塞进可被预知的黑匣子中，你会相信吗？也许多数人都这句话有些茫然，不妨来具体下：不仅是青年，现在的老人和孩子在闲暇时都喜欢抱着手机刷个不停，形容难听点是“像中毒了一样”。

大量的信息流平台正在通过算法偏好来迎合我们，向自身投喂相似的内容，它会造成什么呢？

一方面会让自身 固定在某个信息圈子中难以逃出，它持续强化你对某些问题的看法， 最后形成价值观。

另一方面信息堆积越多， 注意力就难以集中在那些复杂的问题上，造成判断力下降，怎么办？

除此外，身边的一切智能设备仿佛也都在尝试主动为你“提供服务”，这不是坏事；但有一些会让我们在不知觉中陷入信息茧房，不妨重新认识下它。

一、信息茧房

我们先来看看它的由来。

2001年美国学者凯斯·桑斯坦（Cass R. Sunstein）在《信息乌托邦——众人如何生产知识》中提出此概念，并针对内容做出分析和讨论，具体指：

人们的信息领域会习惯地被自身的兴趣所引导，从而将生活桎梏于像蚕丝般一样的「茧房」中的现象。

这个词汇的源头可以追溯到一本新闻传播专业考研必读的书籍，美国计算机科学家、麻省理工学院教授，尼葛洛庞帝的 《数字化生存》，它为什么这么厉害呢？

要知道，20世纪90年代中后期，中国开始兴起互联网创业大潮，年轻的互联网创业者们纷纷有感机遇来临，但对能否把握住这份机遇却心存忐忑，它的出现犹如“盲人指路”， 被奉为互联网时代的「指路圣经」。

令人惊讶的是：25年后的今天在打开书中多半描述已经成为现实，主要围绕三个阶段的预言：

从原子到比特；
代理人界面；
后信息时代。

1. 第一阶段

我想，上过初中三年级的人应该都熟悉，在化学中原子是变化中最小的微粒；如果你不懂没关系，可以用文科的方式理解： 世界万物都是由原子构成，原子组合后构成分子，分子就像瓦砖，堆成各种物质。

它也是人类最经典且使用最广泛的基础假设，用来精准的解释物理学中的力学，热力学、光学、量子学等多方面的问题，甚至还能解释自然科学中的生物学等等。

而尼葛洛庞帝看来，上世纪90年代，大多数信息都是以「原子」的形式呈现，例如：录像带、杂志、报纸、和书籍，长期以来大家对此也习以为常。

但随着计算机技术的发展，即时的电子数据传输就会成为主流的传播方式，我们进而进入比特（binary digit，简称BIT）组成的世界。

原因在于信息是最小单位，它没有重量能以光速方式快速传播，并且无成本拷贝并不会被区域所隔。

这种新的方式能帮助信息摆脱时空的限制，成为全球共享资源，为各个领域的发展带来便利，同时也能促进互联网和计算机的普及。

2. 第二阶段

在上世纪90年代美国计算机学界还是程序设计语言、操作系统和网络协议天下时，尼葛洛庞帝召集一帮各领域专家创立家「媒体实验室」的机构，聚焦研究人机互动。

当时人们把计算机研究重点主要放在 “人如何使用它”并没有关注 “如何和计算机更好相处”。

而基于此问题，他又提出新的概念为 “计算机设计需要人性化界面、此界面应该是使用人代理模式”，什么意思呢？

电脑界面必须像你的管家助手那样能够认识你，了解你的爱好、品位、倾向与需求；甚至还要知晓你的社交朋友圈、理解你的表达语言和肢体动作。

非常厉害吧，为此当时他认为 触屏技术、眼球追踪、语言识别甚至互联网人格的相关研究会是大趋所势，目前看来这些在现在均已经实现。

3. 第三阶段

尼葛洛庞帝在上述基础上，进一步设想了智能计算机将为人类生活带来巨大改变。

他预言到下一步互联网会进入「极端个人化的信息时代」，即算法推荐；在后信息时代里，电脑、手机APP会基于它对你的了解为自身推荐定制化信息。

从前，大众媒体把一模一样的信息通过广播或电视无差别的推荐给每个人；而未来APP会主动对信息进行筛选，并通过界面为使用者制作独一无二的“个人摘要”。

那么，如果按照此指导手册发展，这意味着什么呢？

这不仅让我心中一惊喜，目前买很多电子设备都不用看使用说明书都可以「语言、行为」控制它，以后岂不是更方便么？

但尼葛洛庞帝认为，美好未来虽到来也会在不知不觉中侵蚀人们的智慧和知识；比如：工作机会的减少，导致更多互联网创业者借助线上平台创造更多知识来与企业协同。

背后意味着复杂的工作交给机器解决，人类创作性工作将很难一步登上山顶，甚至非常优秀的创作也很难人性化的被发现，与此未来你可能更多的是和“机器交流”。

那么，严重的是机器取代大部分人力的潮流必不可当，针对发展肯定力大于弊；更加严重的是随着算法推荐带来的信息茧房和数字鸿沟，会加深一个人与另一个人的距离感。

比如：你习惯看历史知识，平台围绕历史中心化展开；若一个天天看娱乐的人被推送的都是八卦，甚至像我这种经常搜“学习内容”的人， 试想下种种场景“会带来什么后果”呢？

我们很难逃出“习惯的周边三公里”。如果不经过主动思考判断或故意去搜寻，会陷入知识获取单一化，没有社会统一认识中，严重者还会造成与社会和企业脱节。

一个现实的案例是：我看到很多离职3个月以上的人，与他们沟通就已经陷入自身的“信息茧房”，对跨岗一丁点技能还能理解，对跨公司业务就直接出现“黑匣子状态”。

不可否认，我们正在经历尼葛洛庞帝教授第三阶段的预测；人们无法阻止数字化的变化，它就像无法对抗大自然一样；但至少每个人可以了解它是如何形成的？如何一步一步吞噬着人们独有的思考模式。

当然，这一切背后离不开人们常说的“算法”或者“个性化推荐”，但它并不是罪魁祸首；那它是什么呢？给自身带来哪些影响呢？

二、算法原理

从框架而言，推荐系统一般包含“召回”和“排序”两方面。

不论是信息还是消费类电商平台，多半以此类型来训练用户，而算法又基于 「内容」和「用户行为」两大类别展开。

我们知道普通人的思维方式分为两种类型：

线性思维；
非线性思维。

前者是把认识停留在对事物的抽象而非本质上，并以这样的抽象为出发点，片面、直线的解释某件事；后者是把认识停留在对事物的抽象层并以基石出发来看底层原理。

机器学习方式和人相似，也分为线性和多种思维（学习）模型， 最主要区别是一方面偏向基础原理，一方面偏向多元化加工；从专业角度出发市面一共有6种常用方式：

过滤算法；
矩阵算法；
因子分解机；
逻辑回归；
梯度提升决策树；
深度神经网络过滤。

它们用在什么位置呢？

要知道，人们看到的所有信息均展示在APP的首页或分类上，在推荐系统中它们属于最上层的展示层， 算法属于中间层，数据是最底层；而 算法的主要功能就是排序和召回，上述的六种模型均服务它们两者。

举个例子：我们经常使用某款APP，它习惯性的抓取自己点击的每个图片或者下方的内容，然后以此用打标签的方式归类在后台中，该行为属于排序，进一步说平台可以收集一个账号的多个标签排序。

可当自身许久没有打开该APP时，机器就基于自身感兴趣的内容，通过push，短信的方式召回我们。

大部分大平台（小红书、抖音、快手）的推荐系统分人工干预和自动推荐两种，前者顾名思义人来操作，后者是给机器设定固定时间来循环使用。

自动推荐是什么呢？

若进一步展开解释，如抖音和头条的监督学习算法 Y=F(Xi ,Xu ,Xc)，这三个函数包含三个维度的变量分别为：

内容；
用户特征；
环境特征。

三者匹配起来是一个复杂的数学问题；市面常用模型有好几种，字节系无非是把多模型混合使用，简单来说就是： 你是谁、你在哪里、你爱看什么？基于这些给你推荐什么。

一般当推荐系统的自动化运作时，它就像山头巡视的小兵，不断从整个物品或者信息聚合中抽取当次需要查询的候选集；根据各种不同维度，如物品、年龄、性别、爱好，场景等种类以及规模的大小对候选集进行推送。

此场景犹如流水线工作的「抽样检查」，也同样用在大部分平台的召回手段上， 具体策略是什么样呢？

其一：内容过滤（Content Filtering）；
其二：协同过滤（Collaborative Filtering）。

资讯类产品的内容审核是不可缺失一部分，主要目的是确保无低质庸俗，保持平台该有的调性； 通常有“先发后审”和“先审后发”两个原则。

场景较轻如网易云，QQ音乐此类阅读、听歌类产品通常是前者；对社区论坛、偏观点讨论、树立权威通常是后者； 因此内容抽检或过滤的基础也是查敏感关键词、重复度、IP发布次数等权重指数。

协同过滤是基于已知部分用户或部分物品的偏好或评分，预测缺失偏好或评分的一种方法。

从切入点上，则可分为基于 “去邻域”的方法（本地生活类平台使用居多）和 隐语义模型（给每个分类中不同维度标签的人进行推送），比较难理解对不对？

举个例子：跟朋友聚餐会习惯性打开美食点评平台去搜索周边餐厅，过程中我们能看到按照公里排行的推荐、也有部分商家的竞价广告。

疑问的是，你会发现那些广告的美食是自己日常爱吃的，并且区域也不是太远，为什么会这么做？

因为可以基于“邻域”做精准的推荐，以此满足用户多频次的消费和深度洞察；如果把“邻域”比作数学的“2”，它左手链接“1”，右手链接数字“3”。

去邻域算法就是把“1”推荐给“3”， 假设不做去中心化折中结果就是上述你看到场景，基于自己搜索习惯、爱好、距离做折中推荐。

对于人工干预比较容易理解，基础的说我基于某类标签做手动推送，如：性别类型、兴趣爱好、话题、KOL量级等。

高维一点会融会贯通几项不同的数据综合考量，好比针对女人中对护肤话题感兴趣，客单价又在多少区间等。

这种方式常见在中小型（百万级用户量）以上的平台，主要特征表现在技术的基础建设已经完成，属于发展中期还完全不能依靠自动化解决。

一方面防止有巨大漏洞出现，造成损失。

另一方面也能运用人工的方式灵活多维度的基于用户（商品）进行推送，比如基于点击率作为推荐指标时，排序算法筛选后，我们会以预测结果为目标。

这些场景中就会用到因子分解，逻辑归因，梯度提升决策树，以及各种神经网络算法，这一切也把它称之为“混合模型”。

但不管怎么样始终都离不开那两大原则“基于用户行为”和“基于内容”； 综合上述，我们能得到什么启发呢？

企业招聘大量研发人员，利用理科的思维逻辑将人的行为特征变成“数据化”，由数据进行颗粒化，最终通过个性化的分析让平台更了解每个人，也就有了那句感同身受的话 “我都没有平台了解我自己”。

但真的是这样吗？这种理解就狭隘了。

你以为平台很了解自己？其实我们不过是把爱好，需求形成的特征进行标签化沉淀在平台上，这造成推荐的内容都在自身的“认知圈内”。

简而言之，每个人在头部资讯（购物）平台看到的展示页均不同， 他代表一个人的视野和爱好，这仿佛似一面镜子疯狂的为你展现热爱的一面，它带来的利弊也是极为可见。

三、孰是孰非

从优劣上有两个方面： 一是良好的认知能力，二是陷入回音室效应。

如果我们能够正确认知到信息茧房如何由来的，或者算法如何基于自身的各种行为形成“虚拟人设”为你定做线上画像；加上我们能够辨别哪些信息是优质的，哪些是不能为我所用， 那就不存在“茧房”。

这就给我们最大的启示是， 很多时候我们听到的未必都是正确的，只有深入并全面了解才会摆脱困境。

比如：很多人拼命的为摆脱算法的囚笼在平台看内容不点赞、不评论、不互动；这就能摆脱它吗？并不能。

反而会为你推荐一大堆乱八七糟的内容让自身眼花缭乱失去对关键信息的辨别的能力。

换句话说， “信息封闭环境”听起来是坏事，这好像人们无法接受其他信息一样，可实际上，这也是一种很常见的现象不是吗？

在没有互联网时，世界上的信息同等无穷尽，新的信息也在产生旧的信息也从未消失，堆积依然很多； 即便人用上一生的精力学习也是有限，真正有所造诣的人都是在冰山上抓住某个一角。

进一步而言，五花八门的信息看始终是看不完的，似乎看来人们不但没有损失什么，反而还让人愈发的认为筛选、寻找自身热爱、匹配自我不同阶段是当下不可缺失的能力。

何况很多时候，各种娱乐类、偏社交短内容平台的push大概率是琐碎事，真正重要的信息你一定会接收到。

假如我们不知道“信息茧房”的概念， 在劣势方面可能会形成持续受害而毫无觉察的状态，这就容易陷入回音室效应中，它有四个关键因素：

隔离；
观点极致化；
观点同质化；
同样信息重复传播。

在隔离角度你可以把它理解成在固有群体或“小圈子”内几乎与外界不怎么交流。

由于没有外部或不同信息进来，内部观点会重在重复传播中不停的在人们心中巩固，促使人们看到与内部观点不同的观点时尽可能否定，从而达到“极端共鸣”。

举个例子：很多人热爱进不同的付费社群来学习，圈子中往往会强调一种东西叫 “价值认同”或“主题认同”，假设某个行为（主题）触发大部人群友的爱好或行为底线，那你可能就会被移除群聊。

当所有人的观点都趋同，那同样的信息传播，变着不同的人去表达意思也就发生多变可质量本身并未提高， 对个人的成长也并没有太大帮助。

这四个关键表现，很好的解释了信息与受众的思维关键；具体而言，回 音室效应不但可以让一个人思维禁锢，还极有可能直接废掉理性思考能力。

根据调查很多受害者是两种状态，一是不乏高等教育的专家学者，二是分辨自控力不高的人。

前者学习几十年光理论不实践，很容易陷入封闭状态中，这种原地踏步造成与现实社会脱节还沉浸在固有的圈子中“津津有味”，殊不知外界已经发生巨大的变化。

后者是那些经常以 “这样学习就是对”“哪个专家说”作为标榜或处事依据的人，他们不习惯以理性的事实为基础，更容易陷入感性层。

正是陷入自己编织的信息茧房之中，才会不停阅读内容高度重复却几乎毫无营养的资讯，这造成自己的认识很难提升到新的层级，不仅荒废了自己还浪费掉整个人生。

种种行为在我看来，所谓的相对封闭环境，即可以是被动也可以成为主动。

被动是别人提供而主动在自己；如改变你获取信息的渠道、屏蔽无效信息、把它们变成高质量这是一种选择。

因此我们所避免的信息茧房可能是错的， “摆脱”不是目的，如何有效的利用它为自身做增值才是最重要的；那如何做呢？有2个认知1个技巧是我在践行的。

四、三个锦囊

掌握的概念越多加上日常灵活运用，才能够减少过错的概率。

有句话叫做 “人无法赚到自身认知之外的钱”，相对的是 “人无法碰到自身认知水平之外的问题”，那么，现在碰到的问题就是自己现阶段的一个上限，具体改变上你可以进行参考：

1. 微调认知基模

基模是人与生俱来的行为模式会随着成长而变化， 它是一种知识分类体系，呈层次化结构，类似于树状图；一般来说并不以某个具体事例为对象，而具有某种程度的一般化和抽象化的性质。

比如可以将方法论提炼成为规律，将规律用在不同领域，它们彼此间都是有关联和结构，只是我们从未发现；并不是凌乱互不相关的保留在记忆中。

1973年，美国学者罗伯特·阿克塞尔罗德在《认知与信息处理过程的基模理论》一文中，提出信息处理的过程模式的解释：它认为 “当我们接触到一个新的事物或者信息时，我们头脑中的相关基模就被激活，参与到信息处理的每个环节当中”。

进一步说：当信息的各项特征与我们认知基模相吻合时，人习惯用原有的解释和态度对待它；当不吻合时，才会对新旧信息进行比较，补充新信息确保新解释和态度。

如果你认识到就会发现，新信息处理结果对认知基模会产生两种影响，其一对旧行为认知的强化，假如有矛盾即使修正形成新基模；其二新信息的处理，会让自己做出分析，推理和判断。

从发展来看，只有不断接触新信息，认知基模才会发展出分支或做结构调整，这也符合神经心理学中“神经元集群（neural ensemble）的解释”。

2. 改善偏食情况

很多人喜欢给自己贴标签，当然他们都有一套逻辑自洽的理论，我不反对也不赞成；我原来也是现在基本不在乎，从我的角度出发往往给的心得是 “年轻不要随意贴标签”，为什么呢？

标签会植入到心智中，无形中渗透自身要往哪个圈子发展、学习什么类型的内容等；这很容易造成“信息偏食”，它会局限的将自我定位。

有人说聚焦不好吗？正确的聚焦在我看来先有中长期目标，如结合3年-5年规划再看当下。

第一方面，人与标签唯一不同在于前者是动态发展后者是静态呈现；今年认为对的，明年可能就会失效。

标签是手段，假设自身认为某个标签在短时间能够让自己有个质的提高，或通过此力量能带来外界优势，反之是不错的选择。

第二方面，即使通过标签或圈子渗透到某个领域中，自身也需要对领域的知识有全面的认知，不要盲目地跟随别人的意见和建议，这样， 受社交媒体下“群体性孤独”的影响几率会不断减少。

那么，对于多元化信息的获取和构建“多元化”的圈子，都是摆脱信息茧房必要的手段，我近些年一直这样才能横跨不同的领域。

3. 多看多听多动手

这句话的具体意思为 “尽可能删掉自己历史浏览痕迹”，遇到喜欢的内容把它立马记录下来或转存在收藏中；这可确保自己看到的内容不是经过刻意被推荐，而是相对随机的。

此方法好处是可以非常立竿见影的起效，坏处是你始终还很难完全避免掉“被种草”，那怎么办呢？

多动手去各种平台获取信息，并非“多动手点赞”；这样可以避免单个平台的误导；就我个人而言，因为我有阅读习惯，所以经常通过RSS（信息聚合）阅读完当天所有新闻。

古人云： 兼听则明，偏信则暗。当自身做到多渠道、全方位的获取随机性的信息时，信息茧房就会失去存在的基础，自然就会不攻自破。

总而言之，它仍然是可被破解和避免的，主要是积极主动行动起来，放弃固有习惯，这可能会让自身逃离舒适区，变得不那么愉快； 我想，比起收益这点付出还算值得。

五、总结一下

最厉害的并不是所谓平台方“算力”或“数据”有多牛，而是人； 不信你想想，平台的技术会磨灭我们看世界的好奇心吗？

并不会，平台多元的分发口径，没有成为“茧”，反而织了一张“网”；而 让自身看到的信息能成为茧房，或许这件事只有自己能办到，不是吗？

作者：王智远

本文由公众号：王智远（ID：Z201440）授权发布于运营派。未经允许，禁止转载

题图来自 Unsplash，基于CC0协议。

七问七答：亲历者讲阿里中台落地的实践

Wed, 21 Aug 2019 20:19:09 CST

笔者2013年转岗到阿里巴巴交易平台，从2014年开始推动阿里巴巴交易运营平台的建设（阿里交易中台的前身），此后推动阿里巴巴交易中台的建设直到2016年离开阿里创业。

本篇文章中，笔者从自己的工作经历出发，为大家介绍了阿里中台落地实践的具体情况。

在过去一年的时间中台这个词流行了起来，从市面上的文章看很多朋友讲中台的时候倾向于把平台等同于中台，甚至是后台当中台。

在打算写这篇文章前我觉得把中台讲的最透彻的就是王健先生的“白话中台”系列 —— 定义中台为“企业级能力复用平台”，特别是用Pace-Layered Application Strategy中的SOD（Systems of Differentiation）来定位中台。

但是还不断有朋友问我中台到底是什么、怎么做，其中还不少资深的产品/研发同学。我完全不怀疑他们的理解能力，那么一定是有地方出现了问题，我把这个问题定位在“落地”。

标杆企业中台的理念已经说了太多，但是极少有人讲如何落地，导致大家不只是没吃过猪肉，也没见过猪跑，只是听说过有猪这么个东西 —— 据说比狗胖，比牛小，不挑食，长肉快。

所以，有了这篇文章，把最近朋友常问到的“中台问题”以及我常讲到的“中台故事”完整呈现一下，让大家有个对中台更真切的体验。

一、到底什么是中台？

交易中台是阿里巴巴中台的第一个项目，从这里讲起大家更容易理解背后的逻辑：我刚进入阿里巴巴交易平台的时候先是开心，因为交易平台是阿里的核心系统，和自己合作的都是技术体系的大牛，做什么需求都丝毫不担心技术实现；

但是不久之后就很困惑，因为交易平台几十个开发，每年（只能）做1000多个需求，研发差不多每天都要加班到晚上10点左右，作为产品经理我一年要开900多个会，每天18:00之后才能正经写写文档做做设计，和研发的下班时间差不多；

但是即便大家这么努力，交易平台的需求周期依然是特别长，整天被业务线投诉。

这个事情困扰了我半年的时间，后来一个晚上和渐疯老师聊的时候聊出了这么一句话 —— 我们建设了很多平台能力，但是缺少管理这些能力的能力 —— 这句话有点儿绕，但在当时我们有种被“点亮”的感觉，因为当时我们面对的问题不是常见的“资源不够”，而是“失去掌控”。

本质上，是集团交易平台快速发展了10年，平台治理没跟上，同时面向业务的视图缺失，导致平台对业务的响应速度跟不上，沟通也不顺畅，有点儿力不从心。

一开始我们要做的东西叫“运营平台”，让常见需求“可配置”，业务变更有地方可查，很朴素的想法，后来进化到“交易中台”，我们一直围绕如何对平台能力的有效管理在做事情，从业务建模、系统改造、管理平台建设，目标都是交易平台能够快速对接、有效管理电商体系内各种商品、资金、交付方面的能力，并用业务可理解的方式呈现、复用、整合。

一直到现在交易中台的建设仍然是按照这个方向在发展，这个过程中“业务视图”被建设的越来越好了（参见极客公园专访玄难的文章）

所以当老板突然说我们要做中台的时候，我的建议是去理解“我们要做中台”这句话背后的诉求：多业务支撑、快速响应前台创新等现实问题。正常的情况下，每家公司做出来的中台都应该是不同的，因为不同阶段面对的问题不同，中台切入的点会不一样。

不过中台还是能有个统一答案：

中台是平台发展到一定规模，业务的扩展和变化超出了平台服务能力后自然生成出来的一个发展策略 —— 即中台是平台向业务进化；
中台的目标是更好的应对业务的变动和差异（王健先生文章中的pace-layered application strategy，SOD层面主要讲的就是这个） —— 业务稳定或者单一小伙伴们认真做好平台化，特别是IT治理就能解决大部分问题了；
中台的价值是通过有效的管理让平台上的各种能力（功能/产品）能够有效复用、快速组合，支持业务更快捷的进行探索和发展 —— 如果老板问中台定什么KPI，最直接的其实就是需求交付时间，只不过这个时间的精准度量也是比较耗精力的。

一句话，千万别把中台当作前后台中间的那个，不在一个维度上；中台这个名字其实是平台的升级版。

二、我们公司有几十个开发，怎么做中台合适？

在问怎么做之前先要回答两个问题：

现有平台的成熟度怎么样 —— 有多少需求是可以基于现有功能做少量开发工作就直接复用的？
现在平台团队人员的成熟度怎么样 —— 应对业务需求的时候能否清晰、高效的分析需求，以高于业务的抽象能力给出方案评估，而不是单纯的“接”需求？

很多公司因为现在平台的能力不足、人员水平不高，希望用中台这个灵丹妙药解决问题；如果现在的平台、团队成熟度不足，那么直接搞中台的结果就是引入了新的瓶颈，而且这个瓶颈比现状还要恶劣，这个瓶颈是 —— 由于不能正确的进行业务和系统抽象，做出来的中台既不能让业务开发更灵活，也没有让平台治理更高效。

传统意义上的“互联网产品经理”在做中台这个事儿上没什么优势，反过来说也是好事，大家水平差不多，谁学习能力强谁能做。

还有个更现实的问题，上面这两个问题，我作为外部人可以直接问然后说现在做中台不靠谱，你作为企业内部的产品研发负责人是很难开口的，那怎么办呢？

咬牙跟老板说能做，然后打着中台的旗号先扎实平台能力，同步以试点的方式由核心到边缘做中台化的包装，挺多朋友真的用了这种方式；
跟老板说实话实说家底不够，然后通过专项支持、feature team的方式先确保对业务的有效支持，系统和人员成熟度提升之后再推动中台建设。

方法无分对错，心里不要有压力，主要看公司文化和老板的风格；结果有好坏，取决于是否能找到一个适合自己公司、业务、团队的实现路径，把中台这个战略落下去。

回想在交易中台落地的过程中，玄难亲自上阵review代码，范禹顶着业务压力让天猫研发团队全力配合，真的是福报，没有他们就没有现在的阿里中台；也可能是正因为是阿里，才有这样的管理者吧 ……

Anyway，这个问题的答案是每个中台产品经理都要自己去寻找适合自身发展阶段的落地路径，活下来，做出来。

三、中台怎样落地？

不能直接讲怎么做，容易把人带到坑里。其实秘诀就是找路径，多学习，活下来。

1. 从哪里开始做？

当初阿里做中台，是从交易开始做的，当初其实是个自然而然的过程，因为我们先做了。

后来我离职创业、加入其他公司，从中台的实践者、到观察者、再到实践者之后，我的判断是：在当下如果想把中台做好，一定是从公司的“强中强”业务出发进行中台的探索，在形成了自身的“中台方法论”之后，再横向铺开。

什么叫做强中强？就是这家公司或这个组织在行业中最有优势，在内部又有影响力的部分，比如阿里的电商平台、学而思的教研、头条的算法。即兼具外部优势和内部影响力。

这个事儿是我创业之后才想明白的，中台的目标是服务业务的，特别是多变性的业务，我们离开单纯的产品，去想基础的商业逻辑，就是无论我们是业务创新还是拓展，最适合的路径都是从自己的核心能力出发，成功率才高。

所以中台本身要“做成” —— 产品落地、价值被认可 —— 就需要内部客户的认可，最优选择就是要选公司内有强势资源、外有强势能力的团队，中台落地遵循这个规律从强势能力、核心能力出发来进行中台化才能够有明显的产出和足够的影响。

而且这种能力甚至未必是IT能力，就像学而思的教研其实是个内容能力，或者华为的组织能力，都是最适合进行中台化的。

反之，弱势能力做中台化，面对的问题将是客户不关心，自身能力跟不上，最终两败俱伤。

逻辑上这么讲大家一般都能够理解，但是现实中能够下决心这么做的老板并不多，怎么说呢，这些把中台落的的“牛逼”公司，可能也就牛在这种战略落地能力上……

不过也不用灰心，中台建设就像打仗一样，争取资源，控制预期，从适合的场景出发不断迭代拿出成效，积小胜为大胜，也会是一条能生存下来的中台建设之路。

2. 用什么方法？

回想阿里交易中台，我们当时采用了两类方法论：

在阿里中台建设的初期，我们习惯性的采用互联网从需求到功能的敏捷方式，遇到哪里的效能有瓶颈我们就工具化的方式解决；

后期引入了基于企业架构的思路，尝试对中台能力进行拆解、建模、系统化的实现，当时TOGAF、eTOM、DDD的东西大家都要学习参考。

两种方法各有优缺点，采用敏捷的方式可以快速的解决当下遇到的各种问题，但是缺少框架、体系上的参考，是一种用to C（消费者）的方式做to B的感觉；而基于企业架构的思路有明确的体系参考，不过企业架构和现有的方法倾向于在相对确定性的业务环境中进行分析和设计，过程比较长。

当时我们抽调了将近10位业务和架构专家，关在会议室里面做业务建模、系统设计，基本上都是以周为单位推进，这个在互联网产品经理视角上基本是高速路上龟速行驶了，不过没办法，一边探索一边前进。还好，过程中不断的有一些成果出来，至少让业务线感知到情况在逐步变好。

如果现在重新做一次，我的路径选择会是：

对内（中台团队），基于TOGAF ADM、DDD这样的企业架构方法论对已有的能力进行梳理，确定哪些能力可以以什么样的方式进行复用；
对外（前台团队），围绕前台的应用场景建设业务“视图”（这个用词不精确，叫界面可能更好），业务什么形态就给什么视图，比如电商的业务视图是什么？电商的业务视图就是人货场的设计；算法的业务视图是什么？业务场景、训练目标、评价策略；组织中台的业务视图是什么？组织目标、分工架构、协作流程。

整体过程中采用敏捷的方法，分期迭代不断修正，因为团队对中台的认识也会在这个过程中不断深化。

前段时间王健老师分享了他们在咨询过程中综合使用了敏捷的框架，然后用TOGAF、DDD（领域驱动设计）、DT（设计思维）的方法，结合工作坊的形式来做中台架构设计，我听的过程中脑补了一下，很真切的能匹配到落地过程中方法、节奏、沟通上的问题，非常受用。

回到前面提到的互联网产品经理怎么做中台，单纯掌握“互联网产品”技能做中台是很容易挖坑的，持续学习企业架构，参考“最佳实践”才可能走出自己的路。

四、互联网产品经理做中台的关键点？

在做中台的那段时间，我感觉自己的时间是 1/3 做业务建模、产品设计方面的工作， 1/3还是要接业务需求，只不过做中台被训练了一轮后谈需求的效率会比原来高，因为自己对平台的理解也更深入了；

剩下 1/3的时间是原来不曾有的一种工作，就是和所有相关方“聊”中台，因为新的产品形态和对接方式会让大家不知道怎么和你合作（对比一下财务报销这么简单的流程，每个新人到公司都会经历一次或者N次被打回重做），如果所有人都不能和你顺畅合作，那距离团队重组也就不远了。

作为一个“中台布道者”，几乎要对上、对下、对前后左右所有相关的团队去聊中台怎么做的、什么进展、带来的价值、怎么有效合作，过程中也会夹带着业务、架构方面的问题去寻求共识。

可以说中台不仅仅是交付一个系统或者是个产品，中台其实是一种工作方式的变化，平台的工作方式比较像职能角色，接需求、实现掉；而中台在做好平台的基础上要更向前一步，去想如何让业务跑的更快。

传统的组织架构有两种基本形态：基于职能的（function），基于产品线的（product/business unit）。中台是从职能架构“衍生”出来的，在中台你要从职能看业务、想业务。

这种架构好不好呢？每一种组织架构都有自身的优缺点，其实中台架构和矩阵架（最典型的一种衍生的组织架构）构遇到的问题很像：矩阵架构永远要面对职能团队人不够分的问题；中台架构则是在技能上要求更高，中台产品经理要更懂业务发展而非单纯的平台能力；

不止一位HR和我吐槽市面上招不到中台产品经理，长期的解决方案是随着大家都开始做中台，必然有更多有经验的中台产品经理被培养出来；短期我只能和他们说，要不看看乙方公司懂企业架构的人才，和“本土”人才互相补位推动中台的建设。

中台，只有当工作流走顺、组织健壮起来的时候，才是真正“把中台做出来”的时候。

五、还有什么要嘱咐的？

互联网产品经理做中台产品真的不容易，就像战役的筹划一样要知进退。

这个知进退是知道能做还是不能做；这个知进退是知道什么时候要主动开始，什么时候要埋头打基本功；这个知进退是知道在哪里面向业务处理变化和差异，在哪里回归平台抽象共同点；同时，这个知进退是知道什么时候大张旗鼓的推广，什么时候静悄悄的改bug。

总之，一个产品经理在自己的职业生涯中能做一次中台，是你的福报。（来自马老师的微笑）

作者：张巍，阿里巴巴前产品专家，电商、教育

本文由 @张巍原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

七年，我摸清了移动推广的所有套路

Wed, 21 Nov 2018 20:20:41 CST

今年是我干移动推广的第七个年头了，在这里我经历了很多很多事情。今天希望是给大家带来一个比较轻松，比较随意一点的、好玩一点的分享，是我在这七年里面感受到的或者看到的一些路上的风景。

第一章：渠道

首先我想问大家一个问题，七年前你用的什么手机？

那时候如日中天的诺基亚，砖头厂，还有摩托罗拉……

安卓在2011年已经超过了之前塞班系统成为我们国内最大的手机系统的阵型，那时候你们iPhone 4 其实也已经发布了。

那好，第二问题，五年前你们用什么APP看视频？

我觉得今日头条这个产品其实无论是对新闻来说，对阅读来说，特别是对广告投放来说，它其实是一个划时代的东西。

其实就是你关心的才是头条，或换成广告语来说，你喜欢看的才是广告。

那好，一年前你们用啥看视频？映客还是虎牙？

为什么会问这一二三个问题呢，这七年以来，大家在手机终端用的一些APP，关注的一些内容其实一直在变化，然后对于推广来说，其实是我们目标还是去营销人，还是以人为本。

所以其实整个推广是随着用户的生活各方面的变化而变化的。

我先讲一下渠道。

大概在2010年的时候，移动是一个非常牛的企业，大家看它在2010年已经 布局了视频、阅读、游戏、动漫、数据、音乐、位置、电子商务的基地，即使现在2017年看，它其实也是很牛的，也是很齐全的。

那好我们来看一下游戏基地，大家看一下这个画面，大部分地方我们推广是可以介入，或者说可以抢流量。但这是毫无意义的。当时是不能直接用钱来解决问题的，就是我们现在口头讲的未商业化。

那个时候我们怎么去抢资源？

移动会对每个合作伙伴评级ABCD，然后A你每个月可以拿什么资源走，B你可以拿什么资源走。

那如何决定这个账户的ABCD？

你提供了多少优质的游戏，所以那时候其实我们有一部分工作是找优质游戏去代理，甚至是收购。

官方活动则还是走比较常规的传包等等的套路。

那好，非常规的套路是什么？这就涉及了公关关系了。

资源还是有限的，任何位置其实它只有一个，你上了别人就没有了，所以为什么要给你，那肯定是优先考虑给熟人。

其次就是联运。

在当时看来这种游戏联运的模式是非常不成熟的，就是找人帮我推这个游戏，假如用户付费了10块钱，我后面反你一块钱。

干到后面大家都觉得找运营这件事有点费力了，那好，请问大家尝试过话费不知不觉的就没了吗？

不知情扣费，就是我在你手机上装一个病毒之类的网页，然后时不时就扣个10块钱、20块钱，然后你去找移动问的时候，他会告诉你你玩了什么游戏。

所以其实移动以前整个套路，或者说移动游戏基地整个套路就是这样的。

那好，其实看完第一个案例，或者说作为一个老推广，我给大家来总结几个注意点。

（1）资源永远是有限的

越优质的资源，就越有限，然后这些资源给了你，他就没有了。

我为什么要给你？或者说你凭什么可以拿到这些优质资源？

所以请记住“资源”，永远是推广的核心。

（2）解决我为什么给你这个资源的问题——人脉跟圈子

在中国，人情或人脉其实永远是各位做商务上面最比较重要的一环，可以解决很多非常规的问题，而非常规的问题你解决了，其实才能提升你作为推广的一个价值，不是说我只会花钱，不是说只能通过投放。

如何会维系这个人脉的圈子呢？

那其实我觉得最正向的第一个是，要 保持好奇心。

这种好奇心是对广告好奇心，是对投放模式的好奇心，是对这个市场行业的好奇心，我现在经常看到一些广告，其实我都觉得挺好玩的，我也挺愿意去研究它们，之后讲的就是 敬畏之心。

推广在各家公司应该也是碰钱碰得最多的，永远都是敏感部门。

如何保证在这条路上不入歧途，或者说是手上干干净净，毕竟大家都不想做着做着就像移动某些中高管就进去吃监狱饭了。

第二章：精准

到后面大家都在折腾是什么东西了，大家其实听到很多人说浏览器。

浏览器其实从塞班开始，它就是大家必备的一个工具。

其实很多推广，在引流的渠道上面，很多都是从浏览器开始的，什么文字链、图片等。

推广很重要的渠道阵地就在这里。

预装，相信大家都接触过，是从水货机，国产机，山寨机，自主刷room等开始的，虽然目前整个量级有一定萎缩，但有路子，还是有量的。

网盟，始于各种内嵌的广告/功能sdk，那时候流量还是比较充足的，目前就剩下积分墙还比较活跃。

论坛，论坛这个东西其实是从PC开始发展的，为什么说论坛，因为下面会有刷系统，因为这种东西都是从论坛下来的，你能刷系统之后，我就能够做自动下载，就是其实我会在你的rom里面植入一点东西，然后达到预装和自动下载的一个效果。

后面就是一些 比较常规的appsotre，第三方应用市场，还有一些大媒体的东西。

其实大家就在折腾渠道， 渠道这个玩意，其实这是我们去接触用户的一个桥梁统称。

今日头条的出现，对于广告投放来说是比较颠覆的。

它能告诉我们这些广告主，用户一些阅读的行为你是可以知道的，你是可以找到有特定阅读行为，或者说特定兴趣行为的一些人，然后它是怎么去判定你这个兴趣行为或者给你打标签。

你读什么文章，看什么文章，搜索什么文章。
账号登录，你总要QQ账号登录，微信登录是吧，其实你的数据你的一些标签，也是会有合作过去的。

还有输入法搜索，还有数据化的合作，其实直到现在，你在京东搜一件什么东西，或者说在淘宝搜一件什么东西，事后到今日头条，它很可能就会给你推荐相类似的一些东西，其实他们是有做底层的数据合作的。

其实就你在安卓装了一个应用之后，其实你的很多东西都是被它知道了，例如 LBS，例如IP，例如push了一些东西，所以它是通过这样标签加以运算联想，来给你打标签的。

广点通，广点通的底层其实是QQ资料的层。

QQ账户不用说了，你填的那些年龄、星座、兴趣等，还有社交账户的，然后腾讯其实它不止QQ，它还有浏览器，它还有其他的一些东西，你的一些聊天记录和搜索行为，也是判断你这个人标签的一些唯度。

之后还是你装了这个APP，你手机里的信息就跑不了了。

我们来看一下这个最近的手机厂商（以小米举例），因为其实你买了这台手机之后，你这个人也就是他的了，为啥呢？

首先他自己有自己的小米账号，还有他杂货铺一系列信息。

他知道你APP安装使用的习惯，你装了什么APP，你的使用时长、你的短信也是知道的，你发的push是否点击，兴趣点的问题，输入法输入行为这个也就不说了，这两个是共同的。

所以基本上你在小米，基本上你能搜的信息，就是接收到的信息，它都知道。

方才介绍的是一些找人的媒体，介绍下 找人的技术——Lookalike。

这个有些什么场景呢？

其实就是我有一群种子用户，这群种子用户是我可以提供的一堆手机号码，然后放到平台上用Lookalike这个技术去找人的时候，它就会把你提供的种子用户在这个平台说表现的标签拎出来，然后去做扩大。

当然后面还有很多这种相延续的一些东西，就是找到这帮人之后，找到这帮人其中有人点的广告之后，那点的广告的这个人在这些之前那些媒体平台里面是个什么标签。

它有十个标签的，那我后面就根据这十个标签再去做扩展，其实就是一个种子用户，然后去筛选用户，然后再去扩大的工具。

刚才在第二部分的时候，我跟大家讲了很多渠道。

到精准的时候，大家聚焦点开始从渠道/媒介往目标人群转移，大家会开始去思考，我这个APP，我需要什么样的人群，我应该如何去找到这些人群，那找到之后，我应该怎么去营销这些人群。

其实是整个精准，整个媒体投放技术升级之后带给推广的一些转化。

第三章：内容

同质化的广告慢慢破坏用户体验，在这时候，我们迎来了内容元年。

国内对广告或者对一些新型投放方式的不停探索，其实大家已经不再停留在一些图片或者说很简单的纯粹说利益上的一些事情。

其实从大家都开始去往高质量的内容去做的时候，会有这三点你可以推：

（1）其实优良的内容是可以被传播的，

它的娱乐性其实大家，会起码对他们的产品或者说他们的品牌留下一定的印象，即使是好的坏的。

（2）内容里面的创意其实是挖掘用户深层次的消费需求

就用借贷广告为例：我已经不跟你说，你可以借多少，多快就能到账，那其实是个产品都能说事情。

而是说你借钱之后，你可以去学习，创业，你不必在低声下气跟亲朋好友借钱，将借钱这个行为往正向的，有意义的目标靠，激发用户对借钱这个行为需求的唤醒。

然后假如我给你灌输了这个之前整个行业都没有讲的概念之后，你就会拉开我跟其他品牌的定位，就会记住之前的一些品牌。

（3）用内容去唤醒这些需求

这些我们的产品需求的时候，那用户的教育程度是会更深的，因为其实你已经帮他联想到，你借这笔钱你其实可以干嘛，然后也是更容易贴合我们生活上的场景。

第四章：品效

最近各个推广人都在讲品效合一，除了给效果广告一个华丽的不背kpi的“衣服”外，实际意义在哪里？

我们应该去怎么理解？

其实品牌玩法就是首先我排除掉完全不可能转化的人，就是这些人是完全不是我的目标用户，然后我去给这些有可能转化的人创造独特的、良好的品牌形象。以提升长期的转化还有毛利率的问题。

“效”则是我们找到最有可能够买，并且是马上转化的人，然后给予他超出预期的一些利益，然后带来直接的盈利或广告效果。

品效合一，这个结合起来的话，在一些传统的行业或者其他行业来说，是先品后效的。

举个例子，以前江湖卖艺的人，他们在做这种表演或者做这种盈利这种活动的时候，他会选一个好的街道或者一个好的地理位置。

然后选一个用户，最起码那些人不能太没钱是吧。时间上，最起码要有流量，我不是深夜来做。敲锣打鼓，然后说各种装逼的话，例如我打遍天下无敌手，什么小混混之王什么的东西，增加自己牛的背书，然后目的是招揽客人为观。

到下午的时候，这个卖艺者就会使出浑身解数，然后胸口碎大石那样去表演，然后目的其实是让围观的这些人尽快的转化成一个付费用户，其实品效，或者说先品后效的一些套路就是这样的。

回到我们的这些互联网投放来说，你很难在一个渠道上面先去跟用户说品牌，然后再去找到这些用户，再去兜回来，我要给你利益，这种操作是很难的，包括了频次和精准的问题。

那到今日，我们有什么样的解决方式去走品效合一的这条路子呢？

那我觉得首先KOL，其实他就是自带品牌的，并且他还自带流量，最牛的话，他能输出内容。

在和KOL的合作上，有非常多的困难点：

KOL只是能影响各自领域上面一小戳人，他的影响力其实很局限的。
他毕竟是我们的合作伙伴，他不能完全跟着我们的内部政策随时调整广告投放时间。

那么第二个在品效合一里面能走的通的，我觉得也就手机厂商这个玩意了。

它其实很简单，现在手机已经成为各位的，说的俗一点其实解决身份问题。你可以不带钱包，但你不能不带手机，这个比身份证还唯一一点。

只要我在这里找到一帮人，给他投品牌广告，然后再去根据点击这些品牌广告的人去做效果投放，其实特别简单的一个品牌合一。

品效合一，它简单吗？

我要怎么让这些人信服我们的品牌？我要给他输出什么内容？我要研究这种品牌投放频次，一个品牌的广告要给这些人骚扰多少次？或者说什么人才能记住这些品牌广告？

点了这些品牌广告或者说这些最有可能转化的人？我要给他什么样的刺激？或者我要结合一些什么场景、时间再给他刺激？

其实这里可以研究的东西，有很大的学问。

其实说了这么多，就是目前品效合一这些方法我们还在探索。

我还在路上，然后期待下一个七年。

作者： PPmoney，公众号：姑婆那些事儿（ID：gupo520）

本文由 @姑婆那些事儿授权发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于CC0协议。

大话后端开发的奇淫技巧大集合

Wed, 23 May 2018 08:00:00 CST

Hi，大家好，很荣幸有这个机会可以通过写博文的方式，把这些年在后端开发过程中总结沉淀下来的经验和设计思路分享出来

模块化设计

根据业务场景，将业务抽离成独立模块，对外通过接口提供服务，减少系统复杂度和耦合度，实现可复用，易维护，易拓展

项目中实践例子：

Before：

在返还购APP里有个【我的红包】的功能，用户的红包数据来自多个业务，如：邀请新用户注册领取100元红包，大促活动双倍红包，等各种活动红包，多个活动业务都实现了一套不同规则的红包领取和红包奖励发放的机制，导致红包不可管理，不能复用，难维护难拓展

After：

重构红包业务
红包可后台管理
- 红包信息管理，可添加，可编辑，可配置红包使用的规则，可管理用户红包
红包奖励发放统一处理
应用业务的接入只需要专注给用户进行红包发放即可

设计概要

Before VS After

产品有时提出的业务需求没有往这方面去考虑，结合场景和未来拓展需要，在需求讨论的时候提出模块化设计方案，并可以协助产品进行设计

通用服务抽离

在项目开发中经常会遇到些类似的功能，但是不同的开发人员都各自实现，或者因为不能复用又重新开发一个，导致了类似功能的重复开发，所以我们需要对能够抽离独立服务的功能进行抽离，达到复用的效果，并且可以不断拓展完善，节约了后续开发成本，提高开发效率，易于维护和拓展

项目中实践例子：

Before

在业务中经常需要对用户进行信息通知，如：短信定时通知，APP消息推送，微信通知，等

开发人员在接到需求中有通知功能的时候没有考虑后续拓展，就接入第三方信息通知平台，然后简单封装个信息通知方法，后续也有类似信息通知需求的时候，另一个开发人员发现当前这个通知方法无法满足自己的需求，然后又自己去了解第三方平台重新封装了通知方法，或者后续需求加了定时通知的功能，开发人员针对业务去实现了个定时通知功能，但是只能自己业务上使用，其他业务无法接入，没有人去做这块功能的抽离，久而久之就演变成功能重复开发，且不易于维护和拓展

After

接触到这种可以抽离通用服务需求的时候，就会与产品确认这种需求是否后续会存在类似的需要，然后建议这把块需求抽离成通用服务，方便后续维护和拓展

设计概要

Before VS After

架构独立服务

项目开发过程中有些需求是与所在项目业务无关，如：收集用户行为习惯，收集商品曝光点击，数据收集提供给BI进行统计报表输出，公用拉新促活业务（柚子街和返还公用），类似这种需求，我们结合应用场景，考虑服务的独立性，以及未来的拓展需要，架构独立项目进行维护，在服务器上独立分布式部署不影响现有主业务服务器资源

项目中实践例子：

架构用户行为跟踪独立服务，在开发前预估了下这个服务的请求量，并会有相对大量的并发请求

架构方案：

项目搭建选择用nodejs来做服务端
- 单进程，基于事件驱动和无阻塞I/O，所以非常适合处理并发请求
- 负载均衡：cluster模块/PM2
架构nodejs独立服务
提供服务接口给客户端
接口不直接DB操作，保证并发下的稳定性
数据异步入库
- 通过程序把数据从：消息队列=>mysql
nodejs+express+redis(list)/mq+mysql

用户行为跟踪服务的服务架构图

高并发优化

高并发除了需要对服务器进行垂直扩展和水平扩展之外，作为后端开发可以通过高并发优化，保证业务在高并发的时候能够稳定的运行，避免业务停滞带来的损失，给用户带来不好的体验

缓存：

服务端缓存
- 内存数据库
  - redis
  - memcache
- 方式
  - 优先缓存
    - 穿透DB问题
  - 只读缓存
    - 更新/失效删除
- 注意
  - 内存数据库的分配的内存容量有限，合理规划使用，滥用最终会导致内存空间不足
  - 缓存数据需要设置过期时间，无效/不使用的数据自动过期
  - 压缩数据缓存数据，不使用字段不添加到缓存中
  - 根据业务拆分布式部署缓存服务器
客户端缓存
- 方式
  - 客户端请求数据接口，缓存数据和数据版本号，并且每次请求带上缓存的数据版本号
  - 服务端根据上报的数据版本号与数据当前版本号对比
  - 版本号一样不返回数据列表，版本号不一样返回最新数据和最新版本号
- 场景：
  - 更新频率不高的数据

服务端缓存架构图

异步

异步编程

方式：
- 多线程编程
- nodejs异步编程
场景：
- 参与活动成功后进行短信通知
- 非主业务逻辑流程需要的操作，允许异步处理其他辅助业务，等

业务异步处理

方式
- 业务接口将客户端上报的数据PUSH到消息队列（MQ中间件），然后就响应结果给用户
- 编写独立程序去订阅消息队列，异步处理业务
场景：
- 大促活动整点抢限量红包
  - 参与成功后委婉提示：预计X天后进行红包发放
- 并发量比较大的业务，且没有其他更好的优化方案，业务允许异步处理
注意：
- 把控队列消耗的进度
- 保证幂等性和数据最终一致性
缺陷：
- 牺牲用户体验

【业务异步处理】架构图

【业务异步处理】除了可以在高并发业务中使用，在上面通用服务的设计里也是用这种架构方式

限流

在类秒杀的活动中通过限制请求量，可以避免超卖，超领等问题
高并发的活动业务，通过前端控流，分散请求，减少并发量

服务端限流
- redis 计数器
- 如：类秒杀活动
客户端控流
- 通过参与活动游戏的方式
- 红包雨/小游戏，等方式

服务降级

当服务器资源消耗已经达到一定的级别的时候，为了保证核心业务正常运行，需要丢卒保车，弃车保帅，服务降级是最后的手段，避免服务器宕机导致业务停滞带来的损失，以及给用户带来不好的体验

业务降级
- 从复杂服务，变成简单服务
- 从动态交互，变成静态页面
分流到CDN
- 从CDN拉取提前备好的JSON数据
- 引导到CDN静态页面
停止服务
- 停止非核心业务，并进行委婉提示

高并发优化概要图

防刷/防羊毛党

大多数公司的产品设计和程序猿对于推广活动业务的防刷意识不强，在活动业务设计和开发的过程中没有把防刷的功能加入业务中，给那些喜欢刷活动的人创造了很多的空子等到你发现自己被刷的时候，已经产生了不小的损失，少则几百几千，多则几万

随着利益的诱惑，现在已经浮现了一个新的职业“刷客”，专业刷互联网活动为生，养了N台手机+N个手机号码+N个微信账号，刷到的奖励金进行提现，刷到活动商品进行低价转手处理，开辟了一条新的灰色产业链

我们要拿起武器(代码)进行自我的防御，风控，加高门槛，通过校验和限制减少风险发生的各种可能性，减少风险发生时造成的损失

这里列出常用套路（具体应用结合业务场景）：

校验请求合法性

请求参数合法性判断
请求头校验
- user-agent
- referer
- … …
签名校验
- 对请求参数进行签名
设备限制
IP限制
微信unionid/openid合法性判断
验证码/手机短信验证码
- 牺牲体验
自建黑名单系统过滤

业务风控

限制设备/微信参与次数
限制最多奖励次数
奖池限制
根据具体业务场景设计… …

应对角色

普通用户
技术用户
专业刷客
- 目前还没有很好的限制方式

防刷/防羊毛党套路概要图

附加

APP/H5中签名规则应该由客户端童鞋开发，然后拓展API给前端JS调用，在H5发起接口请求的时候调用客户端拓展的签名，这样可以避免前端JS里构造签名规则而被发现破解

并发问题

多操作

场景：

当==同用户==多次触发点击，或者通过模拟并发请求，就会出现多操作的问题，比如：签到功能，一天只能签到一次，可以获得1积分，但是并发的情况下会出现用户可以获得多积分的问题

剖析：

简化签到逻辑一般是这样的：

查询是否有签到记录 –> 否 –> 添加今日签到记录 –> 累加用户积分 –> 签到成功
查询是否有签到记录 –> 是 –> 今日已经签到过

假设这个时候用户A并发两个签到请求，这时会同时进入到【查询是否有签到记录】，然后同时返回否，就会添加两条的签到记录，并且多累加积分

解决方案：

最理想简单的方案，只需要在签到记录表添加【签到日期】+【用户ID】的组合唯一索引，当并发的时候只有会一条可以添加成功，其他添加操作会因为唯一约束而失败

库存负数

场景：

当==多用户==并发点击参与活动，如：抽奖活动，这个时候奖品只有一个库存了，理论上只有一个用户可以获得，但是并发的时候往往会出现他们都成功获得奖品，导致奖品多支出，加大了活动成本

剖析：

有问题的逻辑流程一般是这样的：

中奖 –> 查询奖品库存 –> 有 –> 更新奖品库存 –> 添加中奖纪录 –> 告知中奖
中奖 –> 查询奖品库存 –> 无 –> 告知无中奖

假设抽奖活动，当前奖品A只有最后一个库存，然后用户A、B、C，同时参与活动同时中奖奖品都是A，这个时候查询商品库存是存在1个，就会进行更新库存，添加中奖纪录，然后就同时中奖了

解决方案：

最理想根本就不需要用多做一个库存的SELECT奖品库存操作，只需要UPDATE 奖品库存-1 WHERE 奖品库存>=1，UPDATE成功后就说明是有库存的，然后再做后续操作，并发的时候只会有一个用户UPDATE成功

总结：

在开发业务接口的时候需要把==同用户==和==多用户==并发的场景考虑进去，这样就可以避免在并发的时候产生数据异常问题，导致成本多支出
可以使用下面的工具进行模拟并发测试：

Apache JMeter
Charles Advanced Repeat
Visual Studio 性能负载

数据采集技巧（番外）

普遍方案

获取平台数据接口
模拟接口请求
数据解析过滤
数据构造入库

使用selenium+Headless自动化测试框架

开发
- 推荐用python开发
  - python+selenium+headless
- 控制请求频率，避免被平台限制请求
- 使用代理IP，绕过请求IP限制
优点
- 无需模拟接口请求
  - 无法攻克数据接口模拟请求(加密签名等)
  - 接口版本频繁变化(需要重新调研)
- 平台接口/页面版本变化，可以快速调整
  - 只需要调整采集数据所在的HTML元素的位置(class/id)
- 可以用户操作/选中/点击/模拟登陆，等
  - 登陆失效后可以模拟登陆
  - 可以发送登陆二维码到钉钉进行扫码登录
应用场景：
- 竞品数据采集
- 淘宝商品价格和自建商品库后台价格监控
- 淘宝领券金额和自建商品库后台券金额监控
- … …

反反爬虫

在做数据采集的过程中，有些平台会对重要数据的请求设置反爬虫策略，避免数据被竞品挖掘和利用，以及消耗大量资源拖垮服务器，反爬虫和反反爬虫是技术之间的较量，这场没有硝烟的战争永不停息。（程序员何必为难程序员）

反爬虫可以分为以下两种
- 服务端限制
  - 服务器端行请求限制，防止爬虫进行数据请求
- 前端限制
  - 前端通过CSS和HTML标签进行干扰混淆关键数据，防止爬虫轻易获取数据
破解服务端限制：
- 模拟设置请求头
  - Referer
  - User-Agent
  - Authorization
  - …..
- 破解签名
  - 签名规则
    - 在JS中找到签名规则
- 控制请求平率
  - 调整请求时间，延迟请求
- 代理IP
  - 切换请求的代理IP，自建/第三方
- 登录限制
  - 带上登录成功后的Cookie/Authorization
- 验证码限制
  - 识图，基于库/第三方
- 投毒破解
  - 为了防止被投毒，需要对数据进行抽样校验
破解前端限制：
- font-face，自定义字体干扰
  - 找到ttf字体文件地址，然后下载下来，使用font解析模块包对ttf文件进行解析，与文字编码进行映射出中文
- 伪元素隐藏式
  - 在CSS里找到xxxx::before {content: “中文”;}对应的中文
- backgroud-image移量
  - 通过背景图片的position位置偏移量和图片中的内容进行映射
- html标签干扰
  - 过滤掉干扰混淆的HTML标签，或者只读取有效数据的HTML标签的内容

总结

作为后端开发者，不仅是完成需求功能开发，要结合业务场景进行合理设计，架构未来，对核心业务进行压测优化，以保证业务在并发下能够正常运行，同时要考虑安全问题以及防刷，防羊毛党，在编码上避免坏代码味道，面相抽象开发，适当使用设计模式，避免技术债

开发应该铭记于心的精句：

技术的存在价值，是让技术推动业务增长，实现公司盈利增长
没有最好的架构只有最适合的架构
开发语言只是工具，在适合的场景中使用适合的工具
抽象思维是从具体存在的各不相同的问题当中洞察问题的本质，理解产品需求的深层次模型，治本而不是治标
知识很重要，她虽然不能直接给你财富，但是可以给你很多机会，活到老学到老

京东亿级商品搜索核心技术解密

Wed, 30 Nov 2016 10:20:07 CST

作者：王春明，现任京东搜索平台部负责人，2011年加入京东搜索团队，期间一直负责京东搜索引擎研发工作，主导了多次搜索架构升级工作保障其满足京东发展需求，擅长搜索引擎、高性能服务开发、分布式系统架构。

招聘：京东搜索平台部木有有高级/资深搜索引擎研发工程师（C/C++) 、高级/资深算法工程师（C/C++）、高级/资深数据系统工程师（java）等职位，期待您的加入，一起打造弹性搜索平台。简历投递至：wangchunming@jd.com，工作地点：北京-北辰世纪中心A座。

京东商品搜索简介

京东商品搜索引擎是搜索推荐部自主研发的商品搜索引擎，主要功能是为海量京东用户提供精准、快速的购物体验。目前入口主要有PC/移动/微信/手Q搜索、移动列表页、店铺搜索、店铺列表等。虽然只有短短几年的时间，系统已经能够支持日均PV过亿的请求，并且经过了多次618店庆和双11的考验。

与人们日常使用的如谷歌、百度等大搜索（或称为“全文搜索”）引擎相比，京东商品搜索引擎与前者有相通之处，比如“覆盖海量数据”、“超高并发查询”以及“超快速的请求响应时间”，同时又有自身显著的业务特点：

结构化的商品数据，需要从商品、库存、价格、促销、仓储等多个系统进行抽取；
极高的召回率要求，保证每一个状态正常的商品都能够被搜索到；
商品信息的及时更新，目的是为了保证用户极佳的购物体验——比如不能给用户展示出下柜的商品，或者商品的实时价格超出了用户搜索限定的范围。这就要求我们的搜索引擎要做到和各个系统的信息时刻保持同步，目前每天更新次数过亿；
逻辑复杂的商品业务，需要存储的商品属性信息是倒排索引信息的2倍之多；
用户购物的个性化需求，要求系统实现用户标签与商品标签的匹配。

正是由于既要兼顾大搜索引擎的通用需求，同时要契合京东的业务特点，我们将系统架构分为四个部分：1. 爬虫系统、2. 离线信息处理系统、3. 索引系统、4. 搜索服务系统。

为了使各位读者能够深入了解京东商品搜索引擎的架构，本文首先介绍了商品搜索的总体架构，然后依次介绍了爬虫系统、离线信息处理系统等各个部分，并且对搜索技术的最新研究方向做展望，希望对各位读者有所帮助。

总体架构

京东商品搜索引擎的整体架构如下图所示：

从上到下共分为3层。最上层是由搜索的前端UI层，负责页面展示。

中间层是由搜索索引服务、SUG搜索、相关搜索、划词服务和兜底服务组成。其中，SUG搜索提供输入框下拉提示词功能；相关搜索提供与query相关的其他搜索词服务；划词服务提供去除query部分词的功能；兜底服务用于索引服务异常情况下提供托底，保证用户基本的搜索可用。

最下层是索引生产端，主要功能是对接商品、库存、价格、促销、仓储等众多外部系统，整合相关数据生产全量和增量数据的索引，为在线检索服务集群提供全量索引和实时索引数据。

爬虫系统

商品搜索引擎的核心是建立商品索引，而建立索引需要详细的商品信息数据。我们利用大数据平台的数据库抽取接口和中间件系统，实现了站内商品爬虫系统，用来抽取数据库中的商品信息和及时发现变化的商品信息。从实践的效果上来看，爬虫系统表现是非常稳定和可靠的。

离线信息处理系统

离线信息处理系统主要功能是用来建立商品搜索引擎的待索引数据，包括全量待索引数据和增量待索引数据。

目前商品全量待索引数据按天进行更新，一部分是商品的基础属性信息，如商品sku、商品名称、颜色、规格、风格、材质面料等等，属于比较稳定、短时期内不会变化的数据。另外一部分是商品销售信息，如商品销量、销售额、评论等，属于易变数据。这些数据散布于多个系统中，使用的存储也各不相同。因此需要对这些来源分散的数据在商品维度进行合并，生成“商品全量待索引宽表”。目前我们建立的全量待索引宽表，不仅应用于搜索引擎服务，还同时应用于个性化推荐等其他产品服务当中。但是仅生成宽表是无法完成搜索引擎的索引需求的，因此我们利用Hadoop/MapReduce计算框架对宽表数据进行清洗，并且依照离线业务逻辑规则对数据进行二次“加工”，最终生成一份全量待索引数据。

有些商品信息，比如“价格”、“库存”、“上下架”等，经常会产生变化，因此对这些数据做全量索引满足不了商品搜索引擎的需求。为了解决数据实时性的强需求，我们建立了增量索引作为全量索引的补充。具体细节上，采用和全量索引类似的方法对数据进行处理，生成增量待索引数据。为了保证增量数据的及时性和准确性，离线信息处理系统会实时调用各商品信息接口获取数据，完成增量待索引数据的在线组装和生产。

索引系统

索引系统是商品搜索引擎的核心，主要功能是把以商品为维度进行存储的待索引数据，转换成以关键字为维度进行存储的数据，用于搜索引擎上层服务进行调用。这里待索引数据指前面离线信息处理系统生成的全量待索引数据和增量待索引数据。

此系统对于全量和增量的处理是一致的，唯一的区别在于待处理数据量的差异。一般情况下，全量数据索引由于数据量庞大，采用Hadoop/MapReduce进行；实时数据量小，采用单机进行索引生产。

为了满足分布式检索的需求，索引系统还会对索引数据进行分片处理，即按照一定策略将索引数据拆分成较小索引片，用于搜索服务系统调用。

搜索服务系统

搜索索引服务系统主要功能是接受用户请求并响应，返回搜索结果。搜索服务系统的发展也经历了从无到有，从简单到丰富到过程。主要分为如下几个阶段：

最初，搜索服务只有1列searcher组成在线检索服务，能够完成一些简单的商品搜索；
随着访问量的增长，搜索服务系统增加了缓存模块，大大加快了请求处理的速度；
接下来为了提高用户体验，我们增加了Query Processor服务，负责用户查询意图分析，提升搜索的准确性。目前Query Processor已经成为了一个融合自然语言处理、机器学习等先进技术的成熟服务，并且还在不断的进行优化；
为了支持个性化，增加了User Profile服务，负责查询用户标签。将商品的标签与用户标签是否匹配，作为一个特征加入排序因子，实现搜索的千人千面；
接着随着数据量（商品量）的增长，我们将结果包装功能从检索服务中独立出去，成为detail服务（基于缓存云实现的商品信息KV查询服务）；
将检索服务进行分片化处理，即采用类似数据库分库分表的思想，对商品id，进行hash处理后进行分片，保证各个分片数据均匀。查询时，将一个搜索请求分配到多个searcher列上，并行检索，进行局部排序后返回给merger。然后merger服务，将多个分片的检索结果进行归并，然后再进行业务排序和加工，确定要返回的商品，最后调用detail服务包装，将结果返给给blender。blender将多个搜索的结果进行融合，返回给前端。需要说明的是，此时搜索服务系统已经成为了一个“多blender&多Searcher&多merger”的系统。今后无论是访问量的增长或者数据量的增长，都可以通过扩容来满足。尤其对于618店庆、11.11之类的峰值搜索量剧增的情况下，可通过增加每个searcher列服务器的数量来满足需求。随着商品数据的不断增加，只要适时对数据做更多的分片，相应增加searcher列就可以了。检索服务分片化机制的建立也标志着京东搜索基础服务系统已经趋于完备。

完整的搜索索引服务架构，如下图所示：

搜索请求流程如下：

外部请求通过vip到达blender；
Blender调用QP，QP调用运营平台，其中运营平台主要负责将日常运营数据服务化，QP负责分析query；
Blender同时请求Merger和其他垂直搜索服务；
Merger调用UserProfile获取用户标签信息；
Merger将请求发给每列searcher；
每个searcher召回商品并返给Merger；
Merger合并多列searcher的结果，确定需要输出的商品，请求Datail包装对应的商品信息；
Detail包装商品信息返给Merger；
Merger将包装好的商品返给blender；
Blender将merger返回的结果与其他垂直搜索结果进行合并，最终返回给前端。

Blender、Merger、Searcher和Detail是整个系统的核心组件，它们之间的调用关系由Clustermap管理。各个模块将自己的服务注册到ClusterMap，同时从ClusterMap订阅其调用模块的信息来确定实际调用关系。

简要搜索服务流程，如下图所示（搜索服务系统内部处理流程）：

图中名词解释如下：

Page cache：页面缓存，blender模块直接缓存输出的页面，merger缓存了多页商品id；
Attr cache：属性缓存，缓存的搜索属性导航区的数据；
Doc cache：缓存查询词从全量索引召回的结果；
OP：运营平台服务，负责搜索运营数据的服务化；
QP：query processor，负责query意图识别。

用户请求发送到blender，首先解析参数。如果命中blender page cache直接返回给用户。如果没有命中，则调用运营平台服务（OP）和QP，并将其传给Merger，Merge会检查是否命中Attr cache，如果命中并且恰好仅请求属性汇总结果，直接返回给blender。否则进一步查看是否命中merger page cahce，如果命中直接调用detail包装，返给blender。如果没有命中，则调用User Profile获取用户标签，将其传给searcher（篇幅所限，图中只列了一个searcher，实际是多个）。Searcher接到请求，判断是否命中doc cache，如果命中doc cache，则拉取增量结果；如果没有命中doc cahe，则拉取全量和增量结果。然后依次进行排序、在线业务处理，把结果返给merger。Merger合并多个searcher结果，排序、在线业务处理，最后调用detail包装，最后将结果返给blender，blender合并多个搜索结果后返回给用户。

作为一个高并发系统，为了保证高召回率和低响应延时，我们把整个搜索服务流程的处理全部放在内存当中进行计算。多个searcher并发处理请求，同时单个searcher内部采用线程池技术，即所有线程之间共享倒排索引和商品属性信息，提高内存使用效率；每个查询使用一个独立线程串行执行，保证并发的多个查询线程之间互不影响。此外通过合理的设置线程池的大小，我们可以保证系统的CPU资源得到充分利用。在上述两个方面对系统进行优化之后，整个搜索服务系统的稳定性、召回率、内存使用率、计算速度等指标都有大幅度的提高。但是我们改进系统的步伐并没有停歇，因为通过实践发现基于内存和线程池的搜索服务仍然有几个瓶颈点亟需解决，主要包括：拉取倒排、排序和在线业务处理。针对这些问题，我们进行了二次优化，主要包括如下措施：

1. 多级缓存策略

Blender Page cache：由于搜索符合互联网的二八法则，20%热门查询频度非常高，占每天搜索请求量80%。针对这一特点，搜索第一级缓存以查询请求为key，将返回给用户的页面作为value。对于完全相同的请求，直接从缓存返回结果。页面缓存策略上线伊始，缓存命中率就接近了30%，基本解决了当时的性能问题。
Merge Page cache：随着业务的发展，排序结果需要针对不同用户实现个性化订制，这就导致请求中会包含用户的user pin。如果直接将user pin放入缓存作为key，会导致blender cache的key数量暴增，不但需要超大的缓存空间，同时缓存的命中率也会极低，最终会导致线上个性化服务的体验满意度降低。为了解决这个问题，将user_pin加入key，但是value只保存排序好的商品id，这样需要的缓存空间远远小于blender cache。当命中缓存后，调用detail直接进行结果包装。为了进一步提高缓存命中率，利用用户搜索的翻页习惯，即离线统计出用户的翻页数TP99，然后在value中缓存这些页面涉及到所有的商品id，从实践效果来看，用户后续的翻页请求大部分会命中cache。
在深入分析了业务和排序的需求之后，我们发现拉取倒排的结果只和“查询词&筛选条件”有关，而与用户无关，因此可以按照“查询词&筛选条件”作为key的方式对其进行缓存。

虽然拉取倒排结果缓存的key很快就解决了，但是我们在解决Value的存储时遇到了两个问题：1）拉取倒排的结果非常之多，导致缓存过大；2）对此结果缓存，会降低实时索引的时效性。

对于问题1），在分析了业务之后，对需要缓存的信息进行了大量的精简并采用压缩存储，最终将一个查询的缓存控制在0.5M以下。

对于问题2），我们将拉取倒排结果分为两部分，第一部分是从全量索引拉取倒排的结果，第二部分是从实时索引拉取倒排的结果。为了和全量索引的更新频率保持同步，我们把第一部分数据进行缓存的周期置为1天。对于第二部分数据，由于增量结果远远少于全量结果（一般增量只有全量5%不到），每次缓存都进行实时计算，这就是图3中的doc cache机制。从实践中来看，命中doc cache的响应时间比未命中的降低了1-2个数量级。将来随着增量结果的积累，如果实时拉取倒排结果成为性能瓶颈，可以对增量索引分段也进行缓存。

2. 截断策略

对于有些热门查询，由于其结果较多，比如“男装”、“鞋”之类的query，原始查询结果几千万个，如果对这些结果挨个进行处理，性能会非常差。同时，从用户角度分析，一个查询只有排在最前面的结果对用户才有意义。通过分析用户翻页次数，可以得到截断保留topN结果。如何保证截断不影响用户体验呢？首先我们对商品建立离线模型，即为每个商品计算出一个质量分数据。然后在索引阶段，将所有商品按照质量分降序排列，保证在倒排链中，排在前面的商品质量分总是高于后面的。在线从前往后拉取倒排过程中，如果结果数达到10*topN时，停止拉取倒排。随后对结果计算文本相关性，再按照文本相关性取topN个。截断算法上线前后，虽然KPI指标无明显变化，但是对大结果查询性能提升了一个数量级。

3. 均匀分片策略

从总体架构图中我们可以看到，如果我们将一个term的倒排链进行均分，那么相应term的拉取倒排也会被分配至各个searcher列。正是由于各个searcher列是并行计算的，这样的均分操作就可以大大减少每个查询的平均响应时间。从理论上来讲，我们采用的均匀分片策略，也有效的契合了拉取倒排、排序、在线业务处理等CPU密集型的任务。但是分片增加，会带来硬件成本增高的后果，同时集群节点间的通信成本也会增加，需要进一步权衡折衷。

4. 业务优化

京东的搜索业务并不只有上面所述的策略和工程逻辑，还必须融合很多业务逻辑。由于每一次搜索几乎都会召回很多结果，如果业务逻辑处理不好，也会导致搜索体验不好。针对这一问题并没有通用的解决方法，但是通过实践我们总结出一个基本原则：在离线阶段完成尽可能多的业务逻辑，减少在线计算量！例如进行搜索排序时，我们需要根据用户搜索历史行为（浏览、点击、购买等）对召回的结果进行排序上的调整，在工程实现上我们会先离线统计出同一个query下所有用户对每个展示商品的行为，然后建立模型，计算出该query下每个商品的权重，将其以hash结构存储；在线排序时，直接以query+商品id为key，取出权重作为反馈特征参与综合排序。

搜索技术的新发展

我们在当前的架构基础之上，正在进行一些新的探索，比如场景搜索和图像搜索。

场景搜索

随着目前京东集团的业务的扩展，用户在使用搜索时，目的不仅仅是查找商品，还可能查询促销活动信息。为了满足这些新的需求，我们在目前商品索引融合了促销系统的数据。我们首先在Query Processor中增加对应意图的识别，然后将促销等数据转换为索引数据。只要Query Processor识别出用户提出这方便的查询意图，将对应的结果返回。

图像搜索

传统搜索仅仅针对文字，但是电商系统的商品图片非常重要，很多购买决策依赖于它。目前我们利用deep learning技术离线训练图片特征，并将其做成索引。当用户使用实拍图或者网图来搜索时，采用相同的方式提取特征，然后从索引中召回最相似商品返回给用户。

文章出处：开涛的博客（订阅号ID：kaitao-1234567）

京东活动系统亿级流量应对之术

Fri, 18 Nov 2016 10:37:40 CST

作者：干天星，2012年初加入京东，先后在京东审计、搭配购、jshop活动系统等项目从事系统研发和架构工作。目前主要负责jshop活动系统架构升级，以及jshop数据中心实现运算架构设计。对构建高并发web架构，以及高性能实时大数据运算，有一定的见解。入职前有过5年电信传统行业开发、架构经验。

背景

京东活动系统是一个可在线编辑、实时编辑更新和发布新活动，并对外提供页面访问服务的系统，地址如http://sale.jd.com/***.html。其高时效性、灵活性等特征，极受青睐，已发展成京东几个重要流量入口之一。近几次大促，系统所承载的PV均为数亿以上。随着京东业务的高速发展，京东活动系统的压力会越来越大。急需要一个更高效，稳定的系统架构，来支持业务的高速发展。本文主要对活动页面浏览方面的性能，进行探讨。

活动页面浏览性能提升的难点：

活动与活动之间差异很大，不像商品页有固定的模式。每个页面能抽取的公共部分有限，可复用性差；

活动页面内容多样，业务繁多。依赖大量外部业务接口，数据很难做到闭环。外部接口的性能，以及稳定性，严重制约了活动页的渲染速度、稳定性；

经过多年在该系统下的开发实践，提出“页面渲染与页面浏览异步化”的思想，页面渲染是把渲染好的整页数据放到redis或者硬盘里了，页面浏览是从redis或者硬盘里取静态的页面，并以此为指导，对该系统进行架构升级改造。通过近几个月的运行，各方面性能都有显著提升。在分享"新架构"之前，先看看我们现有web系统的架构现状。

web架构发展与现状

*浏览服务

以京东活动系统架构的演变为例，这里没有画出具体的业务逻辑，只是简单的描述下架构。

我们会在消耗性能的地方加缓存，这里对部分查库操作加redis缓存。

并且对页面进行整页redis缓存：由于活动页面内容繁多，渲染一次页面的成本是很高。这里可以考虑把渲染好的活动内容整页缓存起来，下次请求到来时，如果缓存中有值，直接获取缓存返回。

以上是系统应用服务层面架构演进的，简单示意。为了减少应用服务器的压力，可以在应用服务器前面，加cdn和nginx的proxy_cache，减少回源率。

整体架构（老）

除了“浏览服务”外，老架构还做了其他两个大的优化：“接口服务”、“静态服务”

访问请求，首先到达浏览服务，把整个页面框架返回给浏览器（有cdn、nginx、redis等各级缓存）；
对于实时数据（如秒杀）、个性化数据（如登陆、个人坐标），采用前端实时接口调用，前端接口服务；
静态服务：静态资源分离，所有静态js、css访问静态服务；
要点：浏览服务、接口服务分离。页面固定不变部分走浏览服务，实时变化、个性化采用前端接口服务实现。

接口服务分两类，直接读redis缓存和调用外部接口。这里可以对直接读redis的接口采用nginx+lua（openresty）进行优化，不做详细讲解。本次分享主要对“浏览服务”架构。

新老架构性能对比

在讲新架构之前先看看新老架构下的新能对比。

*老架构浏览服务性能

击穿cdn缓存、nginx缓存，回源到应用服务器的流量大约为20%-40%之间，这里的性能对比，只针对回源到应用服务器的部分。

浏览方法TP99如下（物理机）

TP99 1000ms左右，且抖动幅度很大，内存使用近70%，cpu 45%左右。1000ms内没有缓存，有阻塞甚至挂掉的风险。

* 新架构浏览服务性能

本次2016 618采用新架构支持，浏览TP99如下（分app端活动和pc端活动）

移动活动浏览TP99稳定在8ms, PC活动浏览TP99 稳定在15ms左右。全天几乎一条直线，没有性能抖动。

新架构支持，服务器（docker）cpu性能如下

cpu消耗一直平稳在1%，几乎没有抖动。

对比结果：新架构TP99从1000ms降低到15ms，cpu消耗从45%降低到1%，新架构性能得到质的提升。

why!!!下面我们就来揭开新架构的面纱。

新架构探索

*页面渲染与页面浏览异步化

再来看之前的浏览服务架构，20%-40%的页面请求会重新渲染页面，渲染需要重新计算、查询、创建对象等导致cpu、内存消耗增加，TP99性能下降。

如果能保证每次请求都能获取到redis整页缓存，这些性能问题就都不存在了。即：页面渲染与页面浏览异步。

*直接改造后的问题以及解决方案

理想情况下，如果页面数据变动可以通过手动触发渲染（页面发布新内容）、外部数据变化通过监听mq自动触发渲染。

但是有些外部接口不支持mq、或者无法使用mq，比如活动页面置入的某个商品，这个商品名称变化。

为了解决这个问题，view工程每隔指定时间，向engine发起重新渲染请求-最新内容放入redis。下一次请求到来时即可获取到新内容。由于活动很多，也不能确定哪些活动在被访问，所以不建议使用timer。通过加一个缓存key来实现，处理逻辑如下。

好处就是，只对有访问的活动定时重新发起渲染。

新架构讲解

*整理架构（不包含业务）

view工程职责：

直接从缓存或者硬盘中获取静态HTML返回，如果没有返回错误页面（文件系统的存取性能比较低，超过100ms级别，这里没有使用）；

根据缓存key2是否过期，判断是否向engine重新发起渲染（如果你的项目外面接口都支持mq，这个功能就不需要了）。

engine工程职责：

渲染活动页面，把结果放到硬盘、redis。

publish工程、mq职责：

页面发生变化，向engine重新发起渲染，具体的页面逻辑，这里不做讲解。

Engine工程的工作就是当页面内容发生变化时，重新渲染页面，并将整页内容放到redis，或者推送到硬盘。

* view工程架构(redis版)

View工程的工作，就是根据链接从redis中获取页面内容返回。

* view工程架构 (硬盘版)

两个版本对比

Redis版

优点：接入简单、性能好，尤其是在大量页面情况下，没有性能抖动。单个dockertps达到700；

缺点：严重依赖京东redis服务，如果redis服务出现问题，所有页面都无法访问。

硬盘版

优点：不依赖任何其他外部服务，只要应用服务不挂、网络正常就可以对外稳定服务；在页面数量不大的情况下，性能优越。单个dockertps达到2000；

缺点：在页面数据量大的情况下（系统的所有活动页有xx个G左右），磁盘io消耗增加（这里采用的javaio，如果采用nginx+lua（OpenResty），io消耗应该会控制在10%以内）。

解决方案

对所有页面访问和存储采用urlhash方式，所有页面均匀分配到各个应用服务器上；

采用nginx+lua（OpenResty）利用nginx的异步io，代替javaio。

*Openresty+硬盘版

现在通过nginx+lua（OpenResty）做应用服务，所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐。通过上述讲解，view工程没有任何业务逻辑。可以很轻易的就可以用lua实现，从redis或者硬盘获取页面，实现更高效的web服务。

通过测试对比，view工程读本地硬盘的速度，比读redis还要快（同一个页面，读redis是15ms，硬盘是8ms）。所以终极版架构我选择用硬盘，redis做备份，硬盘读不到时在读redis。

这里前置机的urlhash是自己实现的逻辑，engine工程采用同样的规则推送到view服务器硬盘即可，具体逻辑这里不细讲。后面有时间再单独做一次分享。

优点：

具备硬盘版的全部优点，同时去掉tomcat，直接利用nginx高并发能力，以及io处理能力；

各项性能、以及稳定性达到最优。

缺点：

硬盘坏掉，影响访问；

方法监控，以及日志打印，需使用lua脚本重写。

总结

无论是redis版、硬盘版、openresty+硬盘版，基础都是页面渲染与页面浏览异步化。

优势：

所有业务逻辑都剥离到engine工程，新view工程理论上永远无需上线；
灾备多样化（redis、硬盘、文件系统），且更加简单，外部接口或者服务出现问题后，切断engine工程渲染，不再更新redis和硬盘即可；
新view工程，与业务逻辑完全隔离，不依赖外部接口和服务，大促期间，即便外部接口出现新能问题，或者有外部服务挂掉，丝毫不影响view工程正常访问；
性能提升上百倍，从1000ms提升到10ms左右。详见前面的性能截图；
稳定性：只要view服务器的网络还正常，可以做到理论上用不挂机；
大幅度节省服务器资源，按此架构，4+20+30=54个docker足以支持10亿级PV。（4个nginxproxy_cache、20个view，30个engine）

结束语

从事开发已有近10载，一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托，对活动系统新架构做了一次简单整理分享给大家，希望能给大家带来一丝帮助。第一次在网上做分享，难免有些没有考虑周全的地方，以后会慢慢的多分享一些自己的心得，大家一起成长。最后再来点心灵鸡汤。。。

文章出处：开涛的博客（订阅号ID：kaitao-1234567）

FAQ系列 | 是什么导致MySQL数据库服务器磁盘I/O高？

Thu, 17 Nov 2016 10:37:59 CST

0、导读

有个MySQL服务器的磁盘I/O总有过高报警，怎么回事？

1、问题

我的朋友小明，TA有个MySQL服务器最近总是报告磁盘I/O非常高，想着我这有免费的不用白不用的企业技术服务（TA自己这么想的），就找我帮忙给把把脉。

作为一个经验丰富(踩坑不断)的DBA，出现这种问题，一般来说，磁盘I/O很高无非是下面几个原因引起：

磁盘子系统设备性能差，或采用ext2/ext3之类文件系统，或采用cfq之类的ioscheduler，所以IOPS提上不去；

SQL效率不高，比如没有索引，或者一次性读取大量数据，所以需要更多的I/O；

可用内存太小，内存中能缓存/缓冲的数据不多，所以需要更多的I/O。

方法论已有，接下来就是动手开始排查了。

2、排查

先看磁盘I/O设备，是由十几块SSD组成的RAID10阵列，按理说I/O性能应该不至于太差，看iops和%util的数据也确实如此。

再来看下文件系统、io scheduler的因素，发现采用xfs文件系统，而且io scheduler用的是noop，看来也不是这个原因。而且看了下iostat的数据，发现iops也不算低，说明I/O能力还是可以的。

再来看看当前的processlist，以及slow query log，也没发现当前有特别明显的slow query，所以也不是这个原因了。

现在只剩下内存不足这个因素了，看了下服务器物理内存是64G，用系统命令 free 看了下，发现大部分都在cached，而free的也不多。观察InnoDB相关的配置以及status，看能不能找到端倪。

首先，看下 innodb-buffer-pool-size 分配了多少：

嗯，分配了18G，好像不是太多啊~

再看一下 innodb status：

重点关注下几个wait值，再看下show engine innodb结果：

关注下unpurge列表大小，看起来还是比较大的（有111万）。

更为诡异的是，在已经停掉SLAVE IO & SQL线程后，发现redo log还在一直增长...

第一次看

停掉SLAVE线程后过阵子再看

看到这里，有经验的DBA应该基本上能想明白了，主要是因为 innodb buffer pool 太小，导致了下面几个后果：

dirty page 和 data page 之间相互“排挤抢占”，所以会出现 Innodb_buffer_pool_wait_free 事件；
redo log 也没办法及时刷新到磁盘中，所以在SLAVE线程停掉后，能看到LSN还在持续增长；
同时我们也看到unpurge的列表也积攒到很大（111万），这导致了ibdata1文件涨到了146G之大，不过这个可能也是因为有某些事务长时间未提交。

还有，不知道大家注意到没，Innodb_row_lock_current_waits 的值竟然是 18446744073709551615（想想bigint多大），显然不可能啊。事实上，这种情况已经碰到过几次了，明明当前没有行锁，这个 status 值却不小，查了一下官方bug库，竟然只报告了一例，bug id是#71520。

3、解决

既然知道原因，问题解决起来也就快了，我们主要做了下面几个调整：

调大innodb-buffer-pool-size，原则上不超过物理内存的70%，所以设置为40G；
调大innodb-purge-thread，原来是1，调整成4；
调大innodb_io_capacity和innodb_io_capacity_max，值分别为2万和2.5万；

调整完后，重启实例（5.7版本前调整innodb-buffer-pool-size 和 innodb-purge-thread 需要重启才生效）。再经观察，发现IOPS下降的很快，不再告警，同时 Innodb_buffer_pool_wait_free 也一直为 0，unpurge列表降到了数千级别，搞定，收工，继续搬砖卖茶~

作者：叶金荣

文章出处：老叶茶馆（订阅号ID：iMySQL_WX）

解密：阿里的运营到底牛逼在哪？

Tue, 15 Nov 2016 20:22:16 CST

如果现在给运营狗们抛出一个问题：运营、营销、策划有什么区别？相信90%的人一口答不上来，脑子飞速的转个几分钟后，才能说几句营销偏资源，运营偏内容，策划偏创意之类的区别。

互联网三座大山，百度、腾讯、阿里巴巴，代表了行业最高水准。

坊间有言：技术看百度，产品看腾讯，运营看阿里。

我有幸能加入阿里做运营，最近工作不忙，居然能从加班狗变成准点下班，所以想记录下在这里的感悟，让自己总结出什么是运营，阿里的运营又不同在哪里。

当然最主要的目的还是逼自己撸出自己的思路，做个合格的运营狗，汪！

思考一下，什么是运营？

这几年跳了几次槽，行业从广告创意平台—媒体零售平台—互动电视渠道零售平台，岗位性质是一样的，带创意性质的策划。

再总结一下，我做的事情，其实就是一件事：营造乐趣，创造买点，留下用户。

问题来了，在我理解中，什么是运营？我以上做的事，是否在运营的范畴里呢？

运营的本质是经营，找对人，节约成本，创造价值。

运营的本源是用户，他是谁?要什么?我就给你什么，留下来相爱。

运营不能用宏大壮烈、大开大合这种词来形容，用润物无声、潜移默化、见微知著更合适。

所以，在我的认知里，运营一直是一个掐细节的工作岗位，细腻敏感抓热点，勤劳快速有创意的女孩子做运营是最适合不过的了（好像把自己黑了？）

然后我来到了阿里。在这里，我对运营有了新的理解。

我在阿里做什么

1、大环境是啥

我所在的事业部，是阿里在O2O上布局的一个从餐饮切入的垂直业务，意图从餐饮行业出发，把“吃”有关的业务全面互联网化;从餐饮切入有好处也有难度，好是因为餐饮是一个用户有刚需和高频的行业;难度是因为这是一个十分复杂，很难被互联网化的传统行业，一家餐厅的选址租房，厨师小工，原料采购，菜品口味都是极难被标准化的，同时还有强大的竞争对手（x团、x评）；

那么我们从哪里切入这个行业呢?餐厅的本质还是饮食的质量和服务的质量，在质量之外，商家最在意的是节约成本、提升效率。

所以数据+工具，是我们的切入点。

所有人都知道，阿里不缺流量，技术上虽然可能不如百度，但怎么说也是三巨头之一必须得服。

流量+工具=数据
工具+数据=营销
数据+营销=用户
很厉害有没有？运营闭环有没有？

没错，这3个公式可以跟商家讲一个完整的精彩的故事，我们这个业务，等于再造一个餐饮淘宝，让商家运用流量、工具、数据，自己在平台上开店做营销，想象空间真是不可限量。

2、我的职责是啥

说到这里要收一收，事业部肩扛集团的战略使命，业务逻辑优秀，那落到执行层面，我作为一个运营有哪些职责呢?

让我做个分析规划先，思路理清楚了才能确定目标和职责。

（1）首先分析一下我的客户是谁

我要为业务同事提供支持：

一线同事专业的是BD技巧，谈判能力，线下资源整合，那么对他们来说，如果有我们的商户在整个城市的覆盖率、品类结构怎么样，哪些品类、地段、客单价的商户表现最佳等数据，是如虎添翼的;

我要为商户提供服务：

比如shopping mall里的商户，我可以策划个活动，让他们抱团打天下，共享资源服务消费者；
比如天气热了，我为小龙虾品类的商户策划活动，给予资源，引爆热点；
比如有营销意识的商家，新菜上架需要推广，我为他们提供流量方案。

我要为用户提供服务：

用户有什么理由在我们的App上进行消费？理由有很多，优惠大、找餐厅方便、推荐精准、有有意思的活动……，对用户来说，能获得有利+有趣的信息就够了。

所以……我特么居然是被3P的?

（2）然后分析一下我在权限下能做些什么

对伙伴：决策参考+风险预警

我的权限能抓取到流量、商户运营、用户、品类、营销活动效果等数据，能为他们提供决策上的数据支持，风险点的预警。

对商户：资源整合+内容策划

我能策划活动，并申请push、App banner资源，能创作出让他们惊喜的内容，能帮助他们整合营销资源。

对用户：决策参考+节约成本

我能根据数据申请补贴的力度，给他们爱的餐厅策划线上线下的主题活动，对C端进行集中的补贴，给他们带来更大优惠;

能根据需求和热点做内容推荐，给他们决策的参考。

对资源：科学分配+投入产出

能根据数据推算出资源匹配的策略;时间线上资源的分配，ROI上资源产出要达标，对象上是扶持中小商家还是给大商家做爆点。

结论出来了，我在阿里做这些

1. 数据运营

我面对比较重要的数据字段有动销率、用户数、单商家产出、转化率等等等。

每天花30-40分钟处理关键字段，做日报表，每周出一份数据周报，看趋势，看长短板进退步，给业务同事反映现象。

一个月左右思考一下本阶段的数据，和竞对的基础数据对比、和兄弟城市的数据对比，往往能看出一些原因。

数据分析是量化的，客观的，从内到外的，能帮助业务管理者做出更科学的决策。

在数据运营上最大的感受是数据一定要自己采集自己处理，一定会比看现成的报表更有趋势感。

2. 内容运营

做内容的目的是创造编辑组织主题内容，提高App的内容价值，从而增强用户粘度和转化，同时用内容配上资源，在恰当的节点推出，可以最大化内容的作用。

一个产品一定是要有内容来填充的，下面是我负责过或配合过的部分内容。

营销活动：偏信息选择，做过一些主题推荐类、热点推荐类、优惠推荐类、shoppingmall推荐类的活动，“西风响，蟹脚痒，来一发大闸蟹？”“水游城餐厅招牌菜0元领”“啤酒和龙虾”等。

内容推荐

偏专栏，化身为一个编辑，用自己的舌头和耳朵，写出和吃有关的故事，让用户看到他们看不到的背后，如“有故事的人，大厨访谈录””独一味的鱼生，南京最有情怀推荐”等，这个也是我自己最喜欢的部分，认识很多餐厅老板、厨师，听到了很多故事，也了解到一道菜背后他们付出的努力，常常让人感动。

线下活动：在shoppingmall、高校、写字楼做过一些简单玩法，没有玩出花样，也是我认为能玩出很多很多花样的有趣的维度。

异业合作：单打独斗没有出路，整合多方资源玩法才多元，和对方品牌找到一个合作切入点，达到双赢是终极目标，比如成功合作的格瓦拉、王老吉、快的打车等等。

3. 资源运营

营销资源是个很宝贵的东西，在互联网行业有很多烧钱补贴大战，烧的就是营销资源，怎么烧呢?除了业务管理者在战略上会有思考外，运营也起到了很关键的作用，因为我们需要在策略下9把资源合理科学的烧掉，所以商户分层+资源匹配策略是一项相当重要的工作。

怎么做？

（1）分层

时间分层：资源预算这种东西一定是不够花的，根据数据运营的结论，我会很清楚每个月的自然峰谷节点，根据内容运营的结论，我会很清楚每个月的活动峰谷节点，根据城市的指标压力，资源要有侧重的分配到时间点，要能冲锋的时候冲起来，并且要平稳的度过整个月，这个道理很简单（一开始经常月底找别的城市借预算这种事我会说？）

商户分层：根据商户的线下流水和在我们平台上的流水，消费者的复购率等数据给出一个标准，把商户分层，ABC不同的商户匹配不同的资源；

A类商户适合放放手，因为能教他给他的都已经给过了，他自己已经可以在规则下跳舞（脑补一下淘宝的大卖家）；

B类商户是重点扶持对象，因为他们有动力有冲劲，可是方法不足资源不足，用资源引导他们成长(脑补读书时20名上下的同学现在都很牛X有没有？）；

C类商户就复杂了，他们基数大，无方法，甚至没有动力，这时候我们的业务同事擅长的就来了，复盘会、培训会，用线下的方式聚集商家，用一个个方案和案例让他们明白思路决定出路，在此基础上，把资源投想他们，帮扶上路！

区域分层：资源向高产出的区域倾斜，比如shoppingmall、热点街区、餐饮消费习惯高的社区。

（2）赛马

赛马是阿里内部的一句土话，意思是在同一规则下的资源竞赛，优秀者得。

分层的目的是为了让我们更了解商户，但资源永远是狼多肉少，所以有一个赛马规则很重要，同一规则下，运用的更好的商户得到资源，进入良性循环。

一般会根据核心指标的排名、增长率排名等数据制定，会权衡发展和健康的比例，激发动力又不要偃苗助长最佳。

看吧，资源运营的依据也是数据，如果没有数据我简直就是个瞎子啊啊啊。

4. 还有在以上脉络之外的2点，创意和沟通

先加2个定语：科学的创意和周密的沟通

（1）创意

创意一定是建立在用户洞察身上的，用户洞察是什么呢?不就是见人说人话，见鬼说鬼话?最终的呈现：文案、设计、玩法。

这几点没啥心得，全凭自己的感觉，总结成一句话就是：我给用户看的，不是一个艺术品，因为用户不会花心思是体会我精心设计的玄妙，他们只想在最短的时间里明白“这是什么鬼?关我P事?简单还是麻烦”举个栗子：抽奖不是创意，创意是怎么抽奖。

插播一个思维工具：大名鼎鼎的六顶思考帽，多多拷问自己的创意。

（2）沟通

内部沟通——创意不走调，信息不流失。

外部沟通——在点子上客户永远比我想象的聪明，在执行上客户永远么有我想象的那么聪明。

执行是需要我的控制的!!!不要觉得不合适，我不控制，效果永远达不到我想要的(这话说的很没底气，因为自己做的也不到位哈哈哈)。

臭表脸的放上几张我自己比较喜欢的作品(见最后)，高手如云，献丑了。

5. 除此以外

还有物料设计、印刷的跟进，H5的搭建，营销活动后台系统的上下线等人肉工作，不赘述了。

6. 写到这里再回头看看

我以前做的是什么：营造乐趣，创造买点，留下用户。

我在阿里做的是什么：数据至上，创造锚点，用好工具，服务客户。

我领悟到什么呢?

想清楚我的客户是谁，也许不只是用户呢?

一切的想法和创意都要有根源，不为了解决问题我费个啥神?

创造锚点而不仅仅是买点，锚点是HTML中超链接的一种，在我这里，意思是我的客户看到我精心设计的锚点，就能像点开超链接一样在自己的脑海里迸发出更多的信息。

全情投入，不投入不足以说困难。

作者：CPDA数据分析天地

来源：http://www.chinaz.com/manage/2016/1025/600065.shtml

本文来源于人人都是产品经理合作媒体@站长之家，作者@CPDA数据分析天地

产品实例：某项目APP后台系统设计

Mon, 26 Dec 2016 16:47:30 CST

今年有幸参与了某度假屋项目从0到1的设计过程，展示给用户的是精致的APP，然而APP背后却是逻辑比较复杂的后台系统。APP的使用体验，很大程度上是由后台系统决定的，后台系统逻辑的合理性决定了APP的核心流程。

业务介绍

简要介绍一下此项目的业务流程如图1所示：

业主购买度假屋并由物业管理公司托管，业主购买度假屋有三种类型：全套、分权、分时，全套即业主购买整套度假屋，分权即业主购买度假屋部分产权，分时即业主购买某季的居住权。

业主每年可以获得一定数量的居住券，分权、分时业主每年获得28张居住券，全套业主每年获得365张优惠券。业主可以选择自住、换住、出租，其中换住是在平台进行，业主将一部分居住券储存在平台，平台返还用户一定数量的换游币，用户可以使用换游币在APP预定其他地区的度假屋并前往居住。所以，此平台是一种度假权益交换的共享度假平台。

图1

后台系统设计

了解业务以后，我们详细介绍后台系统的设计思路，后台的主要系统构成以及流程如图2所示：

图2

销控管理系统主要对度假屋的销售情况进行管理，以及线上的销售合同管理；物业管理系统对度假屋托管情况进行管理，以及线上的物业托管合同管理。

业主托管并签订合同后，业主信息将传递给会员中心和空间管理系统，空间系统根据淡旺平季以及度假屋类型，分发给业主相应的居住券。

业主可以用居住券在APP储存，储存成功后获得平台的换游币。居住券的储存，换游币的换算等动作都是通过super后台系统，同时，super系统还要对空间管理系统的房屋进行包装，最终在APP展示相应的房源。

super系统是APP的核心后台系统，分为运营、客服、超级管理员三种角色，运营主要对系统中的房源信息进行编辑；客服查看订单和会员相关信息，同时可以帮助业主储存居住券。

用户在APP下单后，订单中心生成入住订单，物业方在PMS系统确认订单，PMS系统主要是物业方进行排房、订单管理、房态房量管理、房价管理等操作。

有的物业方没有PMS系统，平台提供了PMS供物业方使用，如果物业方原来就有PMS，则平台提供E-Booking系统供物业方与平台对接，E-Booking系统是平台与物业方确认房源、房屋底价录入、房态房型管理、结算等操作的对接系统。

总结

作为项目的产品经理，首先需要对业务非常熟悉，要做到懂系统人群里最懂业务的，懂业务人群里最懂系统的，这样才能将业务逻辑很好的融合进系统，转换成系统流程。后台产品经理与前台产品经理，前者需要深刻理解业务，将现有的业务流程落实到系统，支撑前台的功能流程；而后者更需要对用户行为进行深入挖掘，对交互和体验有一种死磕精神。

本文只是粗略的说明了此项目后台的系统功能及流程，具体的每个系统还有比较复杂的内部功能逻辑，后续文章会做详细的说明，敬请期待~

本文由 @悠闲小生原创发布于人人都是产品经理。未经许可，禁止转载。

Linux运维领域的开源工具体系汇总

Thu, 16 Mar 2017 20:42:17 CST

操作系统：

Centos,Ubuntu,Redhat,SuSE,Freebsd

网站服务：

nginx,apache,lighttpd,php,tomcat,resin

数据库：

MySQL,MariaDB,PostgreSQL

DB中间件：

maxscale,MyCat,atlas,cobar,amoeba,MySQL-proxy

代理相关：

lvs,keepalived,haproxy,nginx,heartbeat

网站缓存：

squid,nginx,varnish

NOSQL库：

Redis,Memcached,MongoDB,HBase,Cassandra,CouchDB

存储相关：

NFS,FastDFS,Moosefs(mfs),Hadoop,glusterfs,lustre

版本管理：

svn,git

监控报警：

nagios,cacti,zabbix,munin,hyperic,mrtg,graphite

域名解析：

bind,powerdns,dnsmasq

同步软件：

scp,rsync,inotify,sersync,drbd

批量管理：

SSH,Ansible,Saltstack,expect,puppet

虚拟化：

kvm,xen

云计算：

openstack,docker,cloudstack

内网软件：

iptables,zebra,iftraf,ntop,tc,iftop

邮件软件：

qmail,posfix,sendmail,zimbra

远程拨号：

openvpn,pptp,openswan,ipip

统一认证：

openldap

队列工具：

ActiveMQ,RabbitMQ,Metaq,MemcacheQ,Zeromq

打包发布：

maven,ants,jenkins

测试软件：

ab,JMeter,Webbench,LoadRunner,http_load,tcpcopy

带宽测试：

smokeping

性能测试：

dd, fio(IOPS测试),iozone(磁盘测试)

日志相关：

rsyslog,Awstats,flume,storm,ELK(Elasticsearch+Logstash+Kibana)

搜索软件：

Sphinx,Xapian,Solr

无人值守：

kickstart,cobbler

软件安装：

rpm,yum（设计rpm包定制及yum仓库构建）

大数据：

HDFS,Hive,Hbase,Zookeeper,Pig,Spark,Mahout,flume,sqoop

开发语言：

Shell,Python,Golang

原文作者：老男孩

原文出处：http://oldboy.blog.51cto.com/2561410/775056/

没数据积累和用户画像，我是这么做头条产品的……

Thu, 27 Apr 2017 14:51:04 CST

本文作者从0到1规划头条产品，在此想把自己的实操经验分享出来，值得一阅。

本来默默划船，在交流会上谈个性化推荐都不惹人注意的今日头条，毫无置疑现在已经被整个BAT围剿，内容领域的企业不自觉把今日头条当做竞争对手，非内容领域的互联网公司也都想来分一杯内容的羹，一夜间，互联网遍地都是feed流，不谈内容推荐算法都不好意思上桌了。

笔者近期有幸从0到1规划头条产品，想把自己的实操经验分享出来，如果对感兴趣的朋友有帮助自然开心，更希望得到业界大佬的批评和指正，毕竟一个人摸索前进，还是很危险的。

1. 明确定位

经常使用阅读产品很大的感受是大平台很容易出现资讯没深度，垂直的内容资讯只在某几个如科技，互联网等几个领域做的还不错，我当时的设想是有没有可能做行业内深度资讯，尤其是一开始切入那些并未互联网化过深的行业，通过一个行业的试点，形成行业头条，在沉淀优质行业知识的同时，以最低成本去复制到其他行业。

思考了挺久之后开始和老板汇报了，省去10000字具体说服过程，最终同意了，因为团队某公司与一个传统行业A有交集，所以一开始的切入行业就是行业A了，下面开始具体执行了，看着一共10多个技术人员，我陷入了深思……

劣势简直不要太明显：

没有数据积累；
没有用户画像；
团队没人从事过行业A。

我要开始作死地做头条产品了……

2. 头条产品整体设计

我开始从三个层面去搭建产品，底层类型标签层，中层数据抓取分析层，顶层业务应用层。

底层类型标签层

底层根据具体行业进行梳理，本来这个过程应该产品和具体行业从业人员配合梳理，但是碍于资源有限，那就我来吧，肯定不足够详尽，但是一开始可以先跑起来。

底层类型标签层分为类型和标签，类型有层级性，数据库预留到7级，实际梳理到3级就差不多了，如行业A，A公司是一个一级类型，A行业制造公司是二级分类，具体制造公司名称是3级类型，每个类型独立建表，每个表里关联海量标签到类型上，如行业A技术这个类型里我们找到行业A技术术语词典，删选后就作为标签关联到A技术这个类型下面，类型数最后梳理了600多，标签数量有10万多，数据库预留状态位，可以视情况进行启用关闭。

中层数据抓取分析层

数据抓取分析层分为爬虫部署，内容来源处理，数据归类。

1、爬虫部署

我以一个技术外行的角度把爬虫分为两类，一类是不定向爬虫，都是一个个单独网站，这种技术消耗较大，需挨个处理，如各个A行业公司的官网新闻中心和行业A平台网站，需单独处理，另一类定向爬虫，主要是有搜索功能的大资讯平台，如今日头条等，代码可复用，写好之后我直接建了一张表，专门放搜索爬虫的关键词，一堆关键词一套代码就可以实现，输入进去就把含有这些关键词的新闻抓取出来了，现在这张表关键词也有700多了，爬取来的内容量实在太大，建议用mongedb处理。

2、内容来源处理

数据过来后先进行来源梳理，划分优质来源和垃圾来源，提升优质来源内容的权重，优质来源主要是各公司官网，垃圾来源是指对具体行业而言，大量无意义的内容来自同一个来源，那么将他认定为垃圾来源，比如一个叫xx说车的来源在建筑行业被认定为垃圾来源，但是将来复制到汽车这个领域的时候，就不再是垃圾来源了，垃圾来源是一个长期的活，现在大概700多了，大部分垃圾来源是今日头条的头条号。

3、数据归类

过滤完垃圾源之后，就开始数据归类了，本质上是将新闻内容归到我们建立的一个个类型上，因为做行业资讯，希望一开始数据准度较高，我当时想了两种方案，第一种是将类型根据自己关联的海量标签按权重建立一个个模型，所有抓取来的文章做全文的分词处理，大量文章统计词频，每篇文章所有分词就有一个总的频率值，和类型模型比对，取相关性较高的，另一种就是把类型下面所属的标签和所有筛选过垃圾源的文章比对，含有标签的文章归到所属类型下面，含有同一类型标签越多，说明该文章相关性越高，为了快速上线就用第二种方案，但是相对，精度就差了一些，当然随着人工的介入，筛出一系列垃圾源，类型和标签维护工作的持续，内容准度好了一些。

顶层业务应用层

业务展现层主要是梳理目标用户感兴趣的关键词，将这些关键词关联到类型标签层的类型，这样，用户订阅关键词之后就可以看到这个关键词所属的内容，前台现在以及上线2个产品，一个订阅平台，行业头条，与之配套的是后台管理中心。

1、订阅平台

订阅平台半封闭，面向行业A企业用户和行业A自媒体从业者，释放出他们感兴趣的关键词，内容准度更高，企业用户订阅关键词，可以看到相关的资讯，看到平台具有的能力后，有欲望定制更多关键词，后台审核后继续部署爬虫，推送数据给用户，同时记录用户的所有行为数据。

2、行业头条

行业头条完全开放，面向准行业从业者以及泛行业爱好者，释放出更多关键词，但是较订阅平台，内容质量稍差，但是目标用户较广，所以寄希望记录用户的所有行为数据（如评论，阅读量，换一批事件，关注关键词等），得到用户反馈，建立用户画像，以达到根据不同用户画像推荐关键词的效果，为真正的推荐做准备。

3、后台管理中心

含有新闻管理，来源管理（优质来源，垃圾来源），类型/标签管理，用户行为管理，推送管理，关键词审核排期管理，评论搜索管理等，具体就不再详述了，有机会再详细介绍，简单的把产品框架梳理了一张图，和上面的论述结合起来，可能更方便理解。

（注：侵权必究）

3. 致同行

不要动不动就要再造个今日头条，如果你的体验和算法做不到比他强百分之五十以上，正面硬刚基本没戏，找准自己的切入点，认清自己的优势；

内容推荐从来都很危险，如果用户不需要的时候推荐，除非做到让用户惊喜，否则就是减分，用户一定要用的产品，用户只能忍着，可有可无的产品，极有可能被用户卸载，这点做公众号的朋友肯定深有感触，每次推送内容都怕掉粉。。

因为对搜索一直比较有兴趣，所以简单阐述一下自己对输入法产品想做内容的建议吧。

用户有自己了解资讯的需求：

主动获取：RSS抓取（google订阅），关注/订阅（即刻）
被打获取：平台推荐（传统门户，新闻网站），垂直类媒体资讯（36K，虎嗅等，最近冯大辉的readhub），个性化推荐（头条，一点资讯）

这一类需求竞争极其大，还有一类是基于特定场景下，对资讯的了解诉求。

比如找工作时，想了解某家公司；吃饭时，想了解附近餐馆的情况。

这一类诉求特别长尾，目前多是怎么被满足的呢？

主动搜索，到百度，知乎等平台搜索，但得到想要的资讯路径很长，比如你和朋友吃饭，你想知道附近有哪些好馆子，搜到的代价就就极高这种场景大量发生在哪里？聊天和查询的时候！这正是我觉得输入法切入资讯的机会，具体来讲：

当和别人聊天说要跳槽，谈的某家公司，输入法输入时有个提示（如颜色变化等）能方便的推送公司的最新资讯；
聊天约饭，方便推送出附近饭馆和评价；
和男朋友说要买赵丽颖同款，男朋友能方便看到这些商品的资讯；

这些诉求的背后数据，词汇出现的频率，输入法公司应该有足够的积累，大可根据词频做内容准备，当用户在输入东西的时候，给用户一个意外的惊喜，来达到资讯推荐的目的，希望有从事输入法这块的朋友能给予指导吧。

作者：小呆（公众号：小呆自留地），野路子出身的产品，非常诚恳的希望有同行能够给出批评和建议~谢谢

本文由 @小呆原创发布于人人都是产品经理。未经许可，禁止转载。

如何基于日志，同步实现数据的一致性和实时抽取?

Mon, 19 Dec 2016 11:00:44 CST

作者：王东

宜信技术研发中心架构师

目前就职于宜信技术研发中心，任架构师，负责流式计算和大数据业务产品解决方案。
曾任职于Naver china（韩国最大搜索引擎公司）中国研发中心资深工程师，多年从事CUBRID分布式数据库集群开发和CUBRID数据库引擎开发
http://www.cubrid.org/blog/news/cubrid-cluster-introduction/

主题简介：

DWS的背景介绍
dbus+wormhole总体架构和技术实现方案
DWS的实际运用案例

前言

大家好，我是王东，来自宜信技术研发中心，这是我来社群的第一次分享，如果有什么不足，请大家多多指正、包涵。

本次分享的主题是《基于日志的DWS平台实现和应用》，主要是分享一下目前我们在宜信做的一些事情。这个主题里面包含到2个团队很多兄弟姐妹的努力的结果（我们团队和山巍团队的成果）。这次就由我代为执笔，尽我努力给大家介绍一下。

其实整个实现从原理上来说是比较简单的，当然也涉及到不少技术。我会尝试用尽量简单的方式来表达，让大家了解这个事情的原理和意义。在过程中，大家有问题可以随时提出，我会尽力去解答。

DWS是一个简称，是由3个子项目组成，我稍后做解释。

一、背景

事情是从公司前段时间的需求说起，大家知道宜信是一个互联网金融企业，我们的很多数据与标准互联网企业不同，大致来说就是：

玩数据的人都知道数据是非常有价值的，然后这些数据是保存在各个系统的数据库中，如何让需要数据的使用方得到一致性、实时的数据呢？

过去的通用做法有几种是：

DBA开放各个系统的备库，在业务低峰期（比如夜间），使用方各自抽取所需数据。由于抽取时间不同，各个数据使用方数据不一致，数据发生冲突，而且重复抽取，相信不少DBA很头疼这个事情。
公司统一的大数据平台，通过Sqoop 在业务低峰期到各个系统统一抽取数据，并保存到Hive表中, 然后为其他数据使用方提供数据服务。这种做法解决了一致性问题，但时效性差，基本是T+1的时效。
基于trigger的方式获取增量变更，主要问题是业务方侵入性大，而且trigger也带来性能损失。

这些方案都不算完美。我们在了解和考虑了不同实现方式后，最后借鉴了 linkedin的思想，认为要想同时解决数据一致性和实时性，比较合理的方法应该是来自于log。

（此图来自：https://www.confluent.io/blog/using-logs-to-build-a-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea/）

把增量的Log作为一切系统的基础。后续的数据使用方，通过订阅kafka来消费log。

比如：

大数据的使用方可以将数据保存到Hive表或者Parquet文件给Hive或Spark查询；
提供搜索服务的使用方可以保存到Elasticsearch或HBase 中；
提供缓存服务的使用方可以将日志缓存到Redis或alluxio中；
数据同步的使用方可以将数据保存到自己的数据库中；
由于kafka的日志是可以重复消费的，并且缓存一段时间，各个使用方可以通过消费kafka的日志来达到既能保持与数据库的一致性，也能保证实时性；

为什么使用log和kafka作为基础，而不使用Sqoop进行抽取呢？因为：

为什么不使用dual write（双写）呢？，请参考https://www.confluent.io/blog/using-logs-to-build-a-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea/

我这里就不多做解释了。

二、总体架构

于是我们提出了构建一个基于log的公司级的平台的想法。

下面解释一下DWS平台， DWS平台是有3个子项目组成：

Dbus（数据总线）：负责实时将数据从源端实时抽出，并转换为约定的自带schema的json格式数据(UMS 数据)，放入kafka中；
Wormhole（数据交换平台）：负责从kafka读出数据将数据写入到目标中；
Swifts（实时计算平台）：负责从kafka中读出数据，实时计算，并将数据写回kafka中。

图中：

Log extractor和dbus共同完成数据抽取和数据转换，抽取包括全量和增量抽取。
Wormhole可以将所有日志数据保存到HDFS中；还可以将数据落地到所有支持jdbc的数据库，落地到HBash，Elasticsearch，Cassandra等；
Swifts支持以配置和SQL的方式实现对进行流式计算，包括支持流式join，look up，filter，window aggregation等功能；
Dbus web是dbus的配置管理端，rider除了配置管理以外，还包括对Wormhole和Swifts运行时管理，数据质量校验等。

由于时间关系，我今天主要介绍DWS中的Dbus和Wormhole，在需要的时候附带介绍一下Swifts。

三、dbus解决方案

日志解析

如前面所说，Dbus主要解决的是将日志从源端实时的抽出。这里我们以MySQL为例子，简单说明如何实现。

我们知道，虽然MySQL InnoDB有自己的log，MySQL主备同步是通过binlog来实现的。如下图：

图片来自：https://github.com/alibaba/canal

而binlog有三种模式：

Row 模式：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
Statement 模式: 每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL来再次执行。
Mixed模式： MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

他们各自的优缺点如下：

此处来自：http://www.jquerycn.cn/a_13625

由于statement 模式的缺点，在与我们的DBA沟通过程中了解到，实际生产过程中都使用row 模式进行复制。这使得读取全量日志成为可能。

通常我们的MySQL布局是采用 2个master主库（vip）+ 1个slave从库 + 1个backup容灾库的解决方案，由于容灾库通常是用于异地容灾，实时性不高也不便于部署。

为了最小化对源端产生影响，显然我们读取binlog日志应该从slave从库读取。

读取binlog的方案比较多，github上不少，参考https://github.com/search?utf8=%E2%9C%93&q=binlog。最终我们选用了阿里的canal做位日志抽取方。

Canal最早被用于阿里中美机房同步， canal原理相对比较简单：

Canal模拟MySQL Slave的交互协议，伪装自己为MySQL Slave，向MySQL Slave发送dump协议
MySQL master收到dump请求，开始推送binary log给Slave(也就是canal)
Canal解析binary log对象(原始为byte流)

图片来自：https://github.com/alibaba/canal

解决方案

Dbus 的MySQL版主要解决方案如下：

对于增量的log，通过订阅Canal Server的方式，我们得到了MySQL的增量日志：

按照Canal的输出，日志是protobuf格式，开发增量Storm程序，将数据实时转换为我们定义的UMS格式(json格式,稍后我会介绍），并保存到kafka中；
增量Storm程序还负责捕获schema变化，以控制版本号；
增量Storm的配置信息保存在Zookeeper中，以满足高可用需求。
Kafka既作为输出结果也作为处理过程中的缓冲器和消息解构区。

在考虑使用Storm作为解决方案的时候，我们主要是认为Storm有以下优点：

技术相对成熟，比较稳定，与kafka搭配也算标准组合；
实时性比较高，能够满足实时性需求；
满足高可用需求；
通过配置Storm并发度，可以活动性能扩展的能力；

全量抽取

对于流水表，有增量部分就够了，但是许多表需要知道最初（已存在）的信息。这时候我们需要initial load（第一次加载）。

对于initial load（第一次加载），同样开发了全量抽取Storm程序通过jdbc连接的方式，从源端数据库的备库进行拉取。initial load是拉全部数据，所以我们推荐在业务低峰期进行。好在只做一次，不需要每天都做。

全量抽取，我们借鉴了Sqoop的思想。将全量抽取Storm分为了2 个部分：

数据分片
实际抽取

数据分片需要考虑分片列，按照配置和自动选择列将数据按照范围来分片，并将分片信息保存到kafka中。

下面是具体的分片策略：

全量抽取的Storm程序是读取kafka的分片信息，采用多个并发度并行连接数据库备库进行拉取。因为抽取的时间可能很长。抽取过程中将实时状态写到Zookeeper中，便于心跳程序监控。

统一消息格式

无论是增量还是全量，最终输出到kafka中的消息都是我们约定的一个统一消息格式,称为UMS(unified message schema)格式。

如下图所示：

消息中schema部分，定义了namespace 是由类型+数据源名+schema名+表名+版本号+分库号+分表号能够描述整个公司的所有表，通过一个namespace就能唯一定位。

_ums_op_ 表明数据的类型是I（insert），U（update），D（删除）；
_ums_ts_ 发生增删改的事件的时间戳，显然新的数据发生的时间戳更新；
_ums_id_ 消息的唯一id，保证消息是唯一的，但这里我们保证了消息的先后顺序（稍后解释）；

payload是指具体的数据，一个json包里面可以包含1条至多条数据，提高数据的有效载荷。

UMS中支持的数据类型，参考了Hive类型并进行简化，基本上包含了所有数据类型。

全量和增量的一致性

在整个数据传输中，为了尽量的保证日志消息的顺序性，kafka我们使用的是1个partition的方式。在一般情况下，基本上是顺序的和唯一的。

但是我们知道写kafka会失败，有可能重写，Storm也用重做机制，因此，我们并不严格保证exactly once和完全的顺序性，但保证的是at least once。

因此_ums_id_变得尤为重要。

对于全量抽取，_ums_id_是唯一的，从zk中每个并发度分别取不同的id片区，保证了唯一性和性能，填写负数，不会与增量数据冲突，也保证他们是早于增量消息的。

对于增量抽取，我们使用的是MySQL的日志文件号 + 日志偏移量作为唯一id。Id作为64位的long整数，高7位用于日志文件号，低12位作为日志偏移量。

例如：000103000012345678。 103 是日志文件号，12345678 是日志偏移量。

这样，从日志层面保证了物理唯一性（即便重做也这个id号也不变），同时也保证了顺序性（还能定位日志）。通过比较_ums_id_ 消费日志就能通过比较_ums_id_知道哪条消息更新。

其实_ums_ts_与_ums_id_意图是类似的，只不过有时候_ums_ts_可能会重复,即在1毫秒中发生了多个操作，这样就得靠比较_ums_id_了。

心跳监控和预警

整个系统涉及到数据库的主备同步，Canal Server，多个并发度Storm进程等各个环节。

因此对流程的监控和预警就尤为重要。

通过心跳模块，例如每分钟（可配置）对每个被抽取的表插入一条心态数据并保存发送时间，这个心跳表也被抽取，跟随着整个流程下来，与被同步表在实际上走相同的逻辑（因为多个并发的的Storm可能有不同的分支），当收到心跳包的时候，即便没有任何增删改的数据，也能证明整条链路是通的。

Storm程序和心跳程序将数据发送公共的统计topic，再由统计程序保存到influxdb中，使用grafana进行展示，就可以看到如下效果：

图中是某业务系统的实时监控信息。上面是实时流量情况，下面是实时延时情况。可以看到，实时性还是很不错的，基本上1~2秒数据就已经到末端kafka中。

Granfana提供的是一种实时监控能力。

如果出现延时，则是通过dbus的心跳模块发送邮件报警或短信报警。

实时脱敏

考虑到数据安全性，对于有脱敏需求的场景，Dbus的全量storm和增量storm程序也完成了实时脱敏的功能。脱敏方式有3种：

总结一下：简单的说，Dbus就是将各种源的数据，实时的导出，并以UMS的方式提供订阅，支持实时脱敏，实际监控和报警。

四、Wormhole解决方案

说完Dbus，该说一下Wormhole，为什么两个项目不是一个，而要通过kafka来对接呢？

其中很大一个原因就是解耦，kafka具有天然的解耦能力，程序直接可以通过kafka做异步的消息传递。Dbus和Wornhole内部也使用了kafka做消息传递和解耦。

另外一个原因就是，UMS是自描述的，通过订阅kafka，任何有能力的使用方来直接消费UMS来使用。

虽然UMS的结果可以直接订阅，但还需要开发的工作。Wormhole解决的是：提供一键式的配置，将kafka中的数据落地到各种系统中，让没有开发能力的数据使用方通过wormhole来实现使用数据。

如图所示，Wormhole 可以将kafka中的UMS 落地到各种系统，目前用的最多的HDFS，JDBC的数据库和HBase。

在技术栈上， wormhole选择使用spark streaming来进行。

在Wormhole中，一条flow是指从一个namaspace从源端到目标端。一个spark streaming服务于多条flow。

选用Spark的理由是很充分的：

Spark天然的支持各种异构存储系统；
虽然Spark Stream比Storm延时稍差，但Spark有着更好的吞吐量和更好的计算性能；
Spark在支持并行计算方面有更强的灵活性；
Spark提供了一个技术栈内解决Sparking Job，Spark Streaming，Spark SQL的统一功能，便于后期开发；

这里补充说一下Swifts的作用：

Swifts的本质是读取kafka中的UMS数据，进行实时计算，将结果写入到kafka的另外一个topic。
实时计算可以是很多种方式：比如过滤filter，projection（投影），lookup，流式join window aggregation，可以完成各种具有业务价值的流式实时计算。

Wormhole和Swifts对比如下：

落HDFS

通过Wormhole Wpark Streaming程序消费kafka的UMS，首先UMS log可以被保存到HDFS上。

kafka一般只保存若干天的信息，不会保存全部信息，而HDFS中可以保存所有的历史增删改的信息。这就使得很多事情变为可能：

通过重放HDFS中的日志，我们能够还原任意时间的历史快照。
可以做拉链表，还原每一条记录的历史信息，便于分析；
当程序出现错误是，可以通过回灌（backfill），重新消费消息，重新形成新的快照。

可以说HDFS中的日志是很多的事情基础。

介于Spark原生对parquet支持的很好，Spark SQL能够对Parquet提供很好的查询。UMS落地到HDFS上是保存到Parquet文件中的。Parquet的内容是所有log的增删改信息以及_ums_id_，_ums_ts_都存下来。

Wormhole spark streaming根据namespace 将数据分布存储到不同的目录中，即不同的表和版本放在不同目录中。

由于每次写的Parquet都是小文件，大家知道HDFS对于小文件性能并不好，因此另外还有一个job，每天定时将这些的Parquet文件进行合并成大文件。

每个Parquet文件目录都带有文件数据的起始时间和结束时间。这样在回灌数据时，可以根据选取的时间范围来决定需要读取哪些Parquet文件，不必读取全部数据。

插入或更新数据的幂等性

常常我们遇到的需求是，将数据经过加工落地到数据库或HBase中。那么这里涉及到的一个问题就是，什么样的数据可以被更新到数据？

这里最重要的一个原则就是数据的幂等性。

无论是遇到增删改任何的数据，我们面临的问题都是：

该更新哪一行；
更新的策略是什么。

对于第一个问题，其实就需要定位数据要找一个唯一的键，常见的有：

使用业务库的主键；
由业务方指定几个列做联合唯一索引；

对于第二个问题，就涉及到_ums_id_了，因为我们已经保证了_ums_id_大的值更新，因此在找到对应数据行后，根据这个原则来进行替换更新。

之所以要软删除和加入_is_active_列，是为了这样一种情况：

如果已经插入的_ums_id_比较大，是删除的数据（表明这个数据已经删除了），如果不是软删除，此时插入一个_ums_id_小的数据（旧数据），就会真的插入进去。

这就导致旧数据被插入了。不幂等了。所以被删除的数据依然保留（软删除）是有价值的，它能被用于保证数据的幂等性。

HBase 的保存

插入数据到Hbase中，相当要简单一些。不同的是HBase可以保留多个版本的数据（当然也可以只保留一个版本）默认是保留3个版本；

因此插入数据到HBase，需要解决的问题是：

选择合适的rowkey：Rowkey的设计是可以选的，用户可以选择源表的主键，也可以选择若干列做联合主键。
选择合适的version：使用_ums_id_+ 较大的偏移量（比如100亿）作为row的version。

Version的选择很有意思，利用_ums_id_的唯一性和自增性，与version自身的比较关系一致：即version较大等价于_ums_id_较大，对应的版本较新。

从提高性能的角度，我们可以将整个Spark Streaming的Dataset集合直接插入到HBase，不需要比较。让HBase基于version自动替我们判断哪些数据可以保留，哪些数据不需要保留。

Jdbc的插入数据：

插入数据到数据库中，保证幂等的原理虽然简单，要想提高性能在实现上就变得复杂很多，总不能一条一条的比较然后在插入或更新。

我们知道Spark的RDD/dataset都是以集合的方式来操作以提高性能，同样的我们需要以集合操作的方式实现幂等性。

具体思路是：

首先根据集合中的主键到目标数据库中查询，得到一个已有数据集合；
与dataset中的集合比较，分出两类：

A：不存在的数据，即这部分数据insert就可以；

B：存在的数据，比较_ums_id_，最终只将哪些_ums_id_更新较大row到目标数据库，小的直接抛弃。

使用Spark的同学都知道，RDD/dataset都是可以partition的，可以使用多个worker并进行操作以提高效率。

在考虑并发情况下，插入和更新都可能出现失败，那么还有考虑失败后的策略。

比如：因为别的worker已经插入，那么因为唯一性约束插入失败，那么需要改为更新，还要比较_ums_id_看是否能够更新。

对于无法插入其他情况（比如目标系统有问题），Wormhole还有重试机制。说起来细节特别多。这里就不多介绍了。

有些还在开发中。

插入到其他存储中的就不多介绍了，总的原则是：根据各自存储自身特性，设计基于集合的，并发的插入数据实现。这些都是Wormhole为了性能而做的努力，使用Ｗormhole的用户不必关心。

五、运用案例

实时营销

说了那么多，DWS有什么实际运用呢？下面我来介绍某系统使用DWS实现了的实时营销。

如上图所示：

系统A的数据都保存到自己的数据库中，我们知道，宜信提供很多金融服务，其中包括借款，而借款过程中很重要的就是信用审核。

借款人需要提供证明具有信用价值的信息，比如央行征信报告，是具有最强信用数据的数据。而银行流水，网购流水也是具有较强的信用属性的数据。

借款人通过Web或手机APP在系统A中填写信用信息时，可能会某些原因无法继续，虽然可能这个借款人是一个优质潜在客户，但以前由于无法或很久才能知道这个信息，所以实际上这样的客户是流失了。

应用了DWS以后，借款人已经填写的信息已经记录到数据库中，并通过DWS实时的进行抽取、计算和落地到目标库中。根据对客户的打分，评价出优质客户。然后立刻将这个客户的信息输出到客服系统中。

客服人员在很短的时间（几分钟以内）就通过打电话的方式联系上这个借款人（潜客），进行客户关怀，将这个潜客转换为真正的客户。我们知道借款是有时效性的，如果时间太久就没有价值了。

如果没有实时抽取/计算/落库的能力，那么这一切都无法实现。

实时报表系统

另外一个实时报表的应用如下：

我们数据使用方的数据来自多个系统，以前是通过T+1的方式获得报表信息，然后指导第二天的运营，这样时效性很差。

通过DWS，将数据从多个系统中实时抽取，计算和落地，并提供报表展示，使得运营可以及时作出部署和调整，快速应对。

六、总结

说了那么多，大致总结一下：

DWS技术上基于主流实时流式大数据技术框架，高可用大吞吐强水平扩容，低延迟高容错最终一致。
DWS能力上支持异构多源多目标系统，支持多数据格式（结构化半结构化非结构化数据）和实时技术能力。
DWS将三个子项目合并作为一个平台推出，使得我们具备了实时的能力，驱动各种实时场景应用。

适合场景包括：实时同步／实时计算／实时监控／实时报表／实时分析／实时洞察／实时管理／实时运营／实时决策

感谢大家的聆听，此次分享到此为止。

Q&A

Q1：Oracle log reader有开源方案吗？

Ａ1：对于Oracle业界也有许多商业解决方案，例如：Oracle GoldenGate(原来的goldengate), Oracle Xstream, IBM InfoSphere Change Data Capture(原来的DataMirror)，Dell SharePlex (原来的Quest)，国内的DSG superSync等，开源的方案好用的很少。

Q2：这个项目投入了多少人力物力？感觉有点复杂。

Q2：DWS是三个子项目组成，平均每个项目5~7人。是有点复杂，其实也是试图使用大数据技术来解决我们公司目前遇到的困难。

因为是搞大数据相关技术，所有团队里面的兄弟姐妹都还是比较happy的：）

其实这里面，Dbus和Wormhole相对固定模式化，容易轻松复用。Swifts实时计算是与每个业务相关比较大的，自定义比较强，相对比较麻烦一些。

Q3：宜信的这个DWS系统会开源么？

A3：我们也考虑过向社区贡献，就像宜信的其他开源项目一样，目前项目刚刚成形，还有待进一步磨炼，我相信未来的某个时候，我们会给它开源出来。

Q4：架构师怎么理解，是不是系统工程师？

A4：不是系统工程师，在我们宜信有多位架构师，应该算是以技术驱动业务的技术管理人员。包含产品设计，技术管理等。

Q5：复制方案是否是OGG?

A5：OGG与上面提到的其他商业解决方案都是可选方案。

文章出处：DBAplus社群（dbaplus）

指数级增长背后，滴滴出行业务系统的架构升级

Tue, 16 Aug 2016 11:52:58 CST

成立四年，估值已超260亿美元，公司指数级发展、业务爆炸式增长，在此背景下，滴滴出行业务系统的架构升级是怎样进行的？本文根据滴滴出行平台产品中心技术总监——杜欢在2016ArchSummit全球架构师（深圳）峰会上的演讲整理而成。

老司机简介

杜欢，滴滴平台产品中心技术总监。2015年加入滴滴，负责公司公共业务、客户端/前端架构和新业务孵化，致力于用技术手段解决业务痛点和提升研发效率，曾作为技术负责人主导公司技术架构升级以支撑公司业务快速迭代的需求。在加入滴滴前有长达五年的创业经历，具有丰富的团队管理经验，熟悉移动互联网应用的整个技术栈。

今天给大家主要介绍的是去年滴滴内部做的一次重大架构升级，滴滴快速发展的过程中，系统的迭代速度和其他方面的设计遇到了很多困难，这次升级就是为了解决这些困难。

去年我们做了一次非常大的重构。上面图中是今天要讲的大纲，我会从问题本身出发，回顾一下整个过程，包括如何发现问题、分析问题和解决方案。最后，我也会提出一些想法，如何规避重蹈这样的覆辙。

挑战在哪里？

首先，我们看一下挑战在哪里。滴滴在出行领域是非常独特的公司，它的独特不在于业务模式多复杂，而在于它的发展非常快。滴滴的成立时间是2012年的6月，到现在为止才经过了四年的时间。

滴滴的成长速度十分惊人，到今天它的估值已经超过260亿美元，融资轮次非常多。如果不是因为竞争非常恶劣，滴滴也不会一直用融资的方法为自己开路。在这样的压力之下，滴滴所有的动作可能都会走形，所有的想法可能因为现在一些短期利益不得不进行一些权衡。

同时，公司的业务也在爆炸式地增长。如果滴滴只做一个业务，原本可以做得非常深入。滴滴从2014年开始加入了专车业务，2015年业务数量增加到七条，2016年已经超过十条。业务急速发展之中大家会思考，到底怎么做才能使这些还不稳定或者还没有想清楚的业务很好地迭代起来。

想到最简单的方法是， 如果新业务跟某个旧业务非常类似但又不完全一样，我们就把旧业务的旧代码复制并修改，这样新业务就做出来了。之前，这种情况经常发生，就造成了很大的问题。

在2015年上半年，滴滴整个系统已经积累了很多问题，分布在乘客App、服务端、Web App之中。特别值得一提的是，服务端的问题并不是性能，而是在于巨大的耦合导致数据紊乱和迭代速度越来越慢。

滴滴的独特性迫使我们独立思考这些问题，所有的解法都要针对滴滴现状，而不是看哪个大公司是怎么做的，然后直接复制过来。

现状是什么？

在解决问题之前，我们需要了解现状是怎样的。如图所示，在2015年下半年，滴滴的系统架构分为四层。最顶层是用户应用，每一个用户应用就是一个端，也就是用户所能看到的入口。然后是接入层，这是非常传统的结构，我们用了Nginx，还专门做了TCP接入层。

在业务层，Web是非常大的集群，有非常大的代码量，我们只对业务做了分割，有策略引擎、司机调度。在数据层，有KV集群、MySQL集群、任务队列、特征存储。这是任何一个初创公司应该有的架构，我们对这个架构并没有做特殊的策划，仅仅在这个技术体系里面把业务逻辑实现出来。

上面这张图可能会比较有趣。右边这个红色的球，代表的是重构之前App依赖的关系。当时我很想梳理一下App在模块之间是如何进行依赖的，然后我就写了一个脚本运行了一下，得到的结果让我很惊讶。我用蓝色的线表示正常的依赖，就是模块A依赖于模块B，A是B的上一层，B不会反过来依赖A，用红色的线表示异常的依赖，即A依赖B、B通过各种手段反过来依赖A，最后发现基本上都是红色的。

做任何模块的拆分，发现不得不面临这样的问题：把任何一个模块取出来就等于把所有模块都取出来，实际上没有做拆分。所以，关键是需要解耦模块结果。这是iOS的情况。安卓的情况更糟糕。

对于Web App来讲，最大的问题在于耦合性。以前滴滴只有出租车这个业务，最开始的Web App只有出租车，后来专车上线了，就在出租车里面加了专车入口，只是业务名不同界面会有小区别，后来加入了快车、代驾，都跟出租车差不多，没遇到太大问题。

再后来有了顺风车，顺风车跟其他功能不一样，整体界面是预约型的，有乘客和车主两种模式。如果在老首页里面开发顺风车成本太大了，需要和出租车业务线的人一起开发业务模块，如果未来做迭代，这种开发模式将非常痛苦。老首页的模块也没有做拆分，代码散落各地，只是通过打包工具拼接在一起，没有做模块化，所以整体情况也比较糟糕。

相比端，API稍好一点的是，API至少在业务维度上是分开的，出租车与专车、快车是分开的两个系统，放在两个仓库里面。不过API也有一个很大的问题，业务代码没有做服务化拆分，没有model 封装，业务所有的API和后台MIS都在一个仓库里，这对系统来说是非常大的一个隐患。

该如何入手？

现状看上去很糟糕，要仔细思考才能入手。最基本的思路是把所有事情分类，就像整理自己家里一样，无论多乱，我们要做的事情就是将东西分门别类放好。因此，最关键的是要了解到底哪些东西应该放在一起，我们用颜色来比喻模块或者代码的归属，核心问题就变成这些模块到底是什么颜色。我们的思路是，先从前面，也就是 从用户入口进行拆分，要先保证所有的模块是足够内聚的，由统一的团队负责。比如，出租车业务线可以完全控制自己的代码，能够写自己的客户端，也能够写自己的Web App，最终只是通过一些工程构建手段将多个业务整合起来变成一个完整的端。

做到这一点之后，所有的业务迭代问题就迎刃而解了，因为业务间已经没有依赖和耦合了。这一步完成之后做的就是重新梳理业务，让业务根据自己模型特点进行一些重构。

最开始的时候，我们考虑的是怎么做代码治理和模块下沉。代码治理本质上就是把各种模块进行染色、再把它们归类的过程。代码治理最难的事情在于消除错综复杂的依赖。到底怎么做才对呢？

首先，一定要把不同模块的代码放在不同仓库里面，使得模块能够物理上隔离。特别是Java、Obj-C这些静态编译的语言，一旦把代码仓库隔离就完全没有办法直接对其他模块产生依赖，至少绝对不会再出现循环依赖。
再者，就看如何把循环依赖通过一些间接层隔离开，比如通过抽象接口隔离开，一点一点把代码拆到不同仓库。
最后，有了这样一个简单的拆分之后，就需要考虑怎么让模块能独立的开发、测试、上线。独立的流程一旦独立起来，就意味着拆分基本上成功了。

模块下沉与代码治理息息相关。如果只是要求把所有代码拆分，而没有合适的拆分方法，这件事情是无法推进下去的。对于程序员来说，他们内心总有一种冲动想做有意思的事情，比如封装一个很有意思的模块给更多程序员用。大家并非不想做封装，只是如果封装并共享出来的代价太大，就会影响大家的热情。

模块下沉是一种机制，一方面我们应该鼓励，另一方面还应该让大家发现这是一件不得不做的事情。如果仅仅对内公开模块列表让大家自由选择，达不到模块下沉的目的。因为人都很懒，不想思考太多，只想尽快把事情完成，大家往往倾向于复制粘贴，也不愿意额外花时间做下沉。

怎么办呢？我们会给所有业务提供一个统一的SDK，里面包含所有能用的组件，大家必须使用它进行开发。如果业务模块稳定了并且比较通用，我们有工具和相应的简单机制把业务模块下沉下来，变成SDK的一部分，长期下去SDK会越来越大，只要SDK里做好分类和规划，上层就会越来越轻，我们可以真正专注于业务逻辑开发。

除了上面这些，最核心的一点在于， 一定要把所有业务都做到“无状态”和“异步化”。

“无状态”这个概念在服务端比较容易理解。一般我们倾向于把各种业务做到无状态，这样容易做水平扩展。在客户端也是一个道理，也要考虑横向扩展性。一个简单的框架往往提供一些最基础的控件，比如按纽、列表，这些都不会耦合任何业务逻辑，所以很容易使用。

但是当业务做起来，大家习惯将一些状态放到业务控件里面，这在一定程度上方便了，但是一旦需要将业务进行重构或者进行模块化下沉的时候，就造成了非常大的困难。例如，一个模块如果大量通过全局变量或单例跟上下游耦合，那么这个模块就很难复用和重构，这些全局变量或单例就是状态。

所以，我们在客户端也提出使用“无状态”的方式，把存储的信息都放到外面。后面我会提到到底应该怎么样去做。

“异步化”也是解耦的方式。服务端的RPC类似于函数调用，如果参数变了，实现和调用的双方都要做改变，这很不透明，也不能够渐进式上线。我们用订阅/发布的模式对 RPC进行解耦，要求所有接口都要异步返回。

在客户端也是这样，比如做数据的缓存，想优化网络，我们不能够期待这个函数是一个同步函数，一定用回调的方式接受所有参数。所以做设计的时候，只要是有可能发生网络请求或者访问磁盘，在客户端也尽量异步请求数据。

刚刚讲的都是相对比较抽象的内容，接下来会说一下滴滴的业务形态本身。

滴滴是一个出行的平台，涵盖的是整个出行领域所有的出行需求。大家出行到底想要什么？就是到达自己想去的地方。实际上，我们的模型可以做得非常抽象和简单。比如，我想要打快车去机场，我就是一个需求方，我的需求会发到很多服务者那里去，服务者会根据特征进行一些匹配。

最基本的特征是服务能力，如果服务者能够开快车并通过了能力验证，这个需求就有可能发给他。如果开出租车的也有能力开快车，但是他还没有在平台上验证这个能力，就只能开出租车。一个人可以验证很多服务，白天可以开快车，晚上可以做代驾，做不同的事。

服务和需求的匹配是通过计价模型和匹配策略来实现的。发送需求的时候需要选择计价模型和车的类型。快车和专车服务过程大同小异，但是价格差别很明显，专车价格会贵很多。通过匹配策略可以实现各种需求的匹配。

例如，选择了拼车，这个需求会尽量匹配已经有拼友和顺路的车。如果选择专车，可以要求这辆车在指定时间来接人，这时候匹配策略会优化倾向这种方式。

滴滴所有的业务基本上都是以这种模式运转的，所有功能都是核心主干或者旁路，只要把业务模型抽象出来，基本上就能够满足大部分的业务了。

基于这样的想法，我们就思考如何设计真正高度抽象的工具。简单起见，我们把滴滴出行的过程抽象成一个框架（见上图），这并不是完整的框架。有颜色的地方表示出租车、快车、专车、代驾共同的流程，只要组合各种流程就可以实现整个业务形态的能力。在这个框架里可以定制所有业务形态的车标、提示语、匹配的模型、计价模型等功能。

当时梳理这个抽象的时候，我们感觉非常兴奋，因为这意味着在这个基础之上就可以简易扩展出滴滴未来的业务形态。只要滴滴还是在做需求和服务的匹配，基本上就离不开这样一种套路。

客户端怎么拆？

然后我们开始落实到具体该怎么拆的问题。

首先就是客户端，最重要的是需要将业务拆出来。以前所有业务放在同一个仓库里，如果不小心提交了一段错误代码就会带来灾难性的后果，所有业务工作可能都会受到影响。以前编译速度也很糟糕，大家可以想象，每次下载代码都会有几个头文件发生改变，由于循环依赖的缘故几乎所有文件都要重编，二三十分钟后才能重新调试，这个过程让人极度崩溃。

对于iOS，我们用cocoapods把业务拆到不同的pod里面；对于安卓，我们把业务拆分打包并用Maven管理起来。我们拆分方法如下图所示，其中虚线框部分展示的是公共框架，最开始没有很细致分割，只是把它放在一个独立仓库里，保证依赖关系充分清楚，后面就可以随时把代码独立出来，使其变成单独的模块。

同时，我们也在开发构建系统。原生的构建系统使用起来会有很多问题，它并不支持多人并行开发，如果要实现一个舒适的工作流就需要定制。我们还做了网络和日志的封装，将其放在下层。还有一个业务整合的基础框架，包括滴滴出行的App界面框架、首页导航栏，各种业务可以注册自己的入口，并在导航栏里进行切换。

业务之间没有任何代码耦合，比如出租车和专车业务没有关联性，那么代码也没有任何相关的地方，这意味着开发出租车业务的时候，完全没有必要实时更新专车代码，集成的时候也不会因为专车代码而造成问题。

最顶层的One Travel可以通过简单的配置分业务包，比如可以输出只有出租车业务的包，在这上面开发测试速度比较快，整体也会比较灵活。One Travel里面只有极少的代码，未来会改成没有代码、通过脚本就可以生成的项目。

怎么做页面的解耦？上图中是一种类似数据库缓存的设计。从客户端角度来看，如果把服务器当做一个数据库，最终状态存储在服务器，而客户端里存着的是跟服务器同步过的最新状态的缓存。客户端不太可能做到精确的数据同步，一定是每隔一段时间同步一次，或者是在关键节点上靠服务器推送得到订单状态变化。

客户端的业务代码其实不关心究竟是如何同步状态的，所以我们专门写了一个缓存服务器状态的Store层，它是热数据。如果不需要最新状态的数据，业务读取Store时可以读到上次同步的数据，假设此时Store从未同步过状态就会自动读取最新状态；如果业务一定要最新状态的数据，那么就显示要求缓存失效，这样Store就会再读取一次获取最新的信息。

Store还可以自动设置失效时间长度，这个机制跟跟做数据库缓存是一样的，为了性能的平衡，要保证读出准确的数据，同时性能也要最优。同时，Store也有责任负责数据更新，当客户端变化可能会让服务器状态变化时，Store可以自动让相关状态失效，这也是管理缓存的一般做法。

做了这样一些解耦之后，令人惊喜的是，我们发现所有界面是可以随意跳转的，虽然没有从发单直接跳到评价的必要性，但实际上只要有这个架构，就可以从界面A跳到界面B，不会有任何问题。

如果跳到另外一个界面，没有发现必要的数据，就从服务器读取，它自己也会报错，整个逻辑非常清晰。如果需要在流程A和流程B之间再增加一个流程C，我们可以把流程C直接加进去，流程C没有破坏A和B之间的依赖，因为原本A和B之间也没有什么依赖。

我们也做一些App的组件化，把从服务端API到客户端逻辑打包在一起，引用客户端组件就可以实现完整功能。实际封装方法略微有点复杂（注：可以阅读另外一篇文章支撑滴滴高速发展的引擎：滴滴的组件化实践与优化）。

图中所示是做平滑移动组件，地图上有很多车在移动，这些车就是地图上的额外信息，把这些车挂在地图上。如果这个控件不存在，地图上就没有车，控件存在，地图上就有车，只要在上面启动控件就好了。

App集成也采用了异步和无障碍的做法，每个业务只需要在仓库里面测试完之后直接打tag，之后就能自动生成整个所有业务的ipa/apk包。

Web App怎么拆？

接下来讲Web App的拆解， 这实际上是纯工程的解耦。

首先，我们需要实现一个简单的公共框架，这跟业务是无关的。我们使用scrat和webpack来实现工程化，将首页拆分成了许多组件，所有的业务可以根据不同配置选择使用哪些组件，同时也保证页面风格的统一、功能的稳定。

如果网络比较糟糕，我们会做一系列的降级，首先出来的会是一些统一的控件，比如上车地点、目的地、广告等，之后会根据定位的结果得到当前开通的业务线列表，并加载业务代码，然后默认选择当前业务线的逻辑。

如果业务线代码加载好了就开始渲染，如果业务加载出错或代码执行出错，业务就会被隐藏。业务线之间也是完全解耦的，大家可以通过公共框架提供的事件机制来通信，但不允许业务之间直接通信。线上的Web App就是如上图所看到的，每个业务线都有一段独立js代码，第一次加载相对较慢，会看到很多请求，如果业务线代码没有更新，下次打开就完全不走网络请求。

我们也做了很多控件，这是内网发布的一些控件（见上图），每个业务只要关注自己的业务逻辑即可，公共的功能都可以使用控件。特别是选择地址的控件，它把前端界面交互和后端API都打包在一起，和客户端一样，只要引用它，就可以直接在Web App使用，无需任何服务端的开发。

服务器API怎么拆？

关于服务器API的拆分，我们最开始希望一次性实现理想方案，但是这个理想方案遇到一些问题。

我先来谈谈理想方案是什么。 首先，滴滴业务一般都是基于订单流转推动各种业务动作。为什么会发生订单流转？是因为对乘客和司机做了一些操作，如果想象成一个客户端系统，就有点类似于触发各种用户事件。客户端动作根本上决定了信息该如何流转，所有事情都应该在客户端触发，触发之后来到了组件这一层，所有动作进行消费，然后进行下一步操作。

比如，用户提出一个需求，发单对需求进行过滤，判断是哪种需求，然后进行一些检查。快车有拼车和不拼车两种，发单的时候就可以知道是拼车还是不拼车，对于统一订单系统来说这就是个标志。无论拼不拼，这个单对用户都一样，无非就是消耗多少人民币、消耗几个座位还是消耗整辆车的问题。

之后分单系统会进行订单的匹配。一旦匹配成功，客户端有很多动作，司机确认接单，乘客可以看到确认。如果直接做成消息，客户端和服务端用一条总线连接，问题就解决了。

这里有一个很大的优点——可拼接，所有东西都组件化了。但是最 大的问题在于抽象程度非常高。这是函数式的思想，要求所有的Worker都是纯函数，纯函数是非常高的要求，上下文状态必须要通过参数才行。我们发现很难做到这一点，因为所有系统必须有状态，一旦这样这个纯函数就不是纯函数了，要依赖外部的变量。

与面向对象设计的思路差异非常大，做函数式设计时很容易陷入一些抉择当中，如何定义输入、输出，如何划分流程。有一些流程划分成三段式，中间的流程异步调出去，又异步调回来继续后续流程，这种设计让人很纠结。

函数很依赖异步化，异步化会让数据流变得复杂。我们思考数据流的流向，以及每次数据流在流转的时候都需要设置的输入、输出。最终，这个方案并没有实施，虽然我们开发了接近半年的时间。

2016年，我们又重新思考了这个问题，这次是比较简单和现实的方法。首先我们进行了一些代码的隔离，把代码分开，之后对系统按照刚才讲的模块进行面向对象的抽象，比如发单就是单独的系统，订单也是一个单独的系统，支付的收银体系是一个系统，评价体系是一个系统。每一个系统变得很简单，互相之间用RPC调用关联起来。

这会有什么缺点呢？长期来讲缺点还是比较明显的，就是不容易扩展。现在我们设计的模型是来源于当前业务现状，如果业务发生改变，比如多了一种车型，就会遇到该如何扩展的抉择：应该提供更多API接口满足新的业务功能，还是在原有API修改上提供更多参数。

两种方法看起来都可以，但是本质上我认为无论用哪种方案都会使模块本身变得越来越臃肿，其实都是把很多种东西融合在一起，并不是很理想。当一个服务臃肿到一定程度之后又会出现以前的问题，又要再次做拆分和重构，甚至整个RPC调用流程都会发生很大震动。

从项目整体实施效果上来讲，这次重构最主要是解决了开发迭代的问题，能够让迭代速度更快。让我们比较意外的情况是，重构前客户端crash率非常高，重构中我们对代码进行了非常多的修改，同时还在用户体验上做了很多优化，但最终crash率反而大幅下降，从以前1%降低到0.3%。

重构后各个业务团队的开发模式发生了根本的变化，以前是各个业务各耦合在一起进行开发，现在各个业务都能独立开发，互不干扰，同时平台还会不断产出更多的公共组件。

如何避免重蹈覆辙？

最后提一下如何重蹈覆辙。我认为， 所有的设计应该是自上而下，先从产品层面上规划核心业务的模式，然后考虑如何让产品技术实现它。如果把业务模式描述成如图所示的核心循环，会非常清楚。我们不仅要考虑现在，还要考虑未来。如果让整个架构保持健康，就要考虑什么功能是真正紧密相关的。

比如在服务端，直觉上感觉各种不同的发单应该是在一起的，但实际上并不是这样。不同车型的发单接口互相之间并没有什么联系，每一种发单都会有独特的个性化定制，这些定制才是真正应该跟发单紧耦合的东西。

所以我们应该从产品角度上考虑，把一种发单所调用的所有相关API放在一起，服务端发生变化，调用的组件也会发生变化，做到发单闭环。刚刚提到的今年服务端的重构的方法，实际上并没有让各个子系统打通，这是一件很遗憾的事。未来如果开发一些新需求，肯定还会涉及多个模块、团队，避免不了一些沟通成本。

另外给大家介绍一下，我们专门做了一个组件平台，叫做魔方组件库，是客户端到服务端的库，我们会继续沉淀更多的客户端到服务端打通的组件，让业务开发更快更轻松。

文章出处：InfoQ

京东评价系统海量数据存储设计

Tue, 16 Aug 2016 12:45:34 CST

作者：韦仕，京东商城交易平台评价社区负责人，2010年加入京东，先后参与了用户、商品、评论等系统的架构升级工作。

京东的商品评论目前已达到数十亿条，每天提供的服务调用也有数十亿次，而这些数据每年还在成倍增长，而数据存储是其中最重要的部分之一，接下来就介绍下京东评论系统的数据存储是如何设计的。

整体数据存储包括基础数据存储、文本存储、数据索引、数据缓存几个部分。

基础数据存储

基础数据存储使用mysql，因用户评论为文本信息，通常包含文字、字符等，占用的存储空间比较大，为此mysql作为基础数据库只存储非文本的评论基础信息，包括评论状态、用户、时间等基础数据，以及图片、标签、点赞等附加数据。而不同的数据又可选择不同的库表拆分方案，参考如下：

评论基础数据按用户ID进行拆库并拆表；
图片及标签处于同一数据库下，根据商品编号分别进行拆表；
其它的扩展信息数据，因数据量不大、访问量不高，处理于同一库下且不做分表即可。

因人而异、因系统而异，根据不同的数据场景选择不同存储方案，有效利用资源的同时还能解决数据存储问题，为高性能、高可用服务打下坚实基础。

文本存储

文本存储使用了mongodb、hbase，选择nosql而非mysql，一是减轻了mysql存储压力，释放msyql，庞大的存储也有了可靠的保障；二是nosql的高性能读写大大提升了系统的吞吐量并降低了延迟。存储的升级过程尝试了cassandra、mongodb等分布式的nosql存储，cassandra适用于写多读少的情况，而 mongodb也是基于分布式文件存储的数据库，介于关系型数据库与非关系型数据库之间，同时也是内存级数据库，mongo写性能不及 cassandra，但读写分离情况下读性能相当不错，因此从应用场景上我们选择了mongodb。mongodb确实不错，也支持了系统稳定运行了好几年。

但从今后的数据增长、业务扩增、应用扩展等多方面考虑，hbase才是最好的选择，它的存储能力、可靠性、可扩展性都是毋庸置疑的。选择了 hbase，只需要根据评论ID构建Rowkey，然后将评论文本信息进行存储，查询时只需要根据ID便能快速读取评论的文本内容，当然也可将评论的其它字段信息进行冗余存储，这样根据评论ID读取评论信息后不用再从mysql进行读取，减少数据操作，提升查询性能。

数据索引

京东的评论是以用户和商品两个维度进行划分的。对于用户而言，用户需要发表评论、上传晒图、查看自己的评论等，因此mysql数据库中只要根据用户ID对评论数据进行拆库拆表进行存储，便能解决用户数据读写问题。而对于商品而言，前台需要将统计商品的评论数并将所有评论展示出来，后台需根据评论的全字段进行检索同时还带模糊查询，而评论数据是按userId进行库表拆分的，现在要按商品去获取评论，显然当前的拆分库是无法实现的。起初考虑过根据商品编号再进行拆库拆表，但经过多层分析后发现行不通，因为再按商品编号进行拆分，得再多加一倍机器，硬件成本非常高，同时要保持用户及商品两维度的分库数据高度一致，不仅增加了系统维护成本及业务复杂度，同时也无法解决评论的数据统计、列表筛选、模糊查询等问题，为此引入了全文检索框架solr（前台）/elasticsearch（后台）进行数据索引。

数据索引其实就是将评论数据构建成索引存储于索引服务中，便于进行评论数据的模糊查询、条件筛选及切面统计等，以弥补以上数据存储无法完成的功能。京东评论系统为此使用了solr/elasticsearch搜索服务，它们都是基于Lucene的全文检索框架，也是分布式的搜索框架(solr4.0后增加了solr cloud以支持分布式)，支持数据分片、切面统计、高亮显示、分词检索等功能，利用搜索框架能有效解决前台评论数据统计、列表筛选问题，也能支持后台系统中的关键词显示、多字段检索及模糊查询，可谓是一举多得。

搜索在构建索引时，属性字段可分为存储字段与索引字段，存储字段在创建索引后会将内容存储于索引文档中，同时也会占用相应的索引空间，查询后可返回原始内容，而索引字段创建索引后不占用索引空间也无法返回原始内容，只能用于查询，因此对于较长的内容建议不进行存储索引。

评论搜索在构建索引时，主键评论ID的索引方式设置为存储，其它字段设置为索引，这样不仅减少索引文件的存储空间，也大大提升了索引的构建效率与查询性能。当然，在使用搜索框架时，业务数据量比较小的也可选择将所有字段进行存储，这样在搜索中查询出结果后将不需要从数据库上查询其它信息，也减轻了数据库的压力。

为了更好地应对前后台不同的业务场景，搜索集群被划分为前台搜索集群和后台搜索集群。

前台搜索集群根据商品编号进行索引数据分片，用于解决评论前台的评论数统计、评论列表筛选功能。评论数统计，如果使用常规数据库进行统计时，需要进行sql上的group分组统计，如果只有单个分组统计性能上还能接受，但京东的评论数统计则需要对1到5分的评论分别进行统计，分组增加的同时随着统计量的增加数据库的压力也会增加，因此在mysql上通过group方式进行统计是行不通的。而使用solr的切面统计，只需要一次查询便能轻松地统计出商品每个分级的评论数，而且查询性能也是毫秒级的。切面统计用法如下：

评论列表，只需根据条件从搜索中查询出评论ID集合，再根据评论ID到mysql、Hbase中查询出评论的其它字段信息，经过数据组装后便可返回前台进行展示。

后台搜索集群，评论后台系统需要对评论进行查询，其中包括关键词高亮显示、全字段检索、模糊查询等，为此solr/elasticsearch都是个很好的选择，目前使用elasticsearch。

未来也计划将前台搜索集群切换为elasticsearch。

数据缓存

面对数十亿的数据请求，直接击穿到mysql、搜索服务上都是无法承受的，所以需要对评论数据进行缓存，在此选择了高性能缓存redis，根据不同的业务数据进行集群划分，同时采用多机房主从方式部署解决单点问题，这样只需要对不同的缓存集群进行相应的水平扩展便能快速提升数据吞吐能力，也有效地保证了服务的高性能、高可用。

当然，缓存设计时还有很多细节可以进行巧妙处理的，如：

当用户新发表一条评论，要实现前台实时展示，可以将新增的评论数向首屏列表缓存中追加最新的评论信息；
评论数是读多写少，这样就可以将评论数持久化到redis当中，只有当数据进行更新时通过异步的方式去将缓存刷新即可；评论数展示可通过nginx+lua的方式提供服务，服务请求无需回源到应用上，不仅提升服务性能，也能减轻应用系统的压力；
对于评论列表，通常访问的都是第一屏的数据，也就是第一页的数据，可以将第一页的数据缓存到redis当中，有数据更新时再通过异步程序去更新；
对于秒杀类的商品，评论数据可以结合本地缓存提前进行预热，这样当秒杀流量瞬间涌入的时候也不会对缓存集群造成压力；通过减短key长度、去掉多余属性、压缩文本等方式节省内存空间，提高内存使用率。

数据容灾与高可用

引入了这么多的存储方案就是为了解决大数据量存储问题及实现数据服务的高可用，同时合理的部署设计与相应的容灾处理也必须要有的。以上数据存储基本都使用多机房主从方式部署，各机房内部实现主从结构进行数据同步。如图：

mysql集群数据库拆库后需要对各分库进行多机房主从部署，系统应用进行读写分离并根据机房进行就近调用，当主机房数据库出现故障后将故障机房的数据操作都切换到其它机房，待故障排除后再进行数据同步与流量切换。

使用主从机房部署的方式所有数据更新操作都要在主库上进行，而当主机房故障是需要通过数据库主从关系的重建、应用重新配置与发布等一系列操作后才能解决流量切换，过程较为复杂且影响面较大，所以这是个单点问题，为此实现数据服务多中心将是我们下一个目标。

多中心根据特定规则将用户分别路由到不同机房进行数据读写，各机房间通过数据总线进行数据同步，当某一机房出现故障，只需要一键操作便能快速地将故障机房的用户流量全部路由到其它机房，实现了数据的多写多活，也进一步实现了服务的高可用。数据多中心如下：

hbase集群目前使用的是京东的公有集群，实现了双机房主备部署，主集群出现故障后自动将流量切换到备用集群，而当hbase整个集群故障时还可对其进行降级，同步只写入缓存及备用存储mongo，待集群恢复后再由后台异步任务将数据回写到hbase当中。

搜索集群根据商品编号进行索引数据分片多机房主从部署，并保证至少3个从节点并部署于多个机房当中，当主节点出现故障后从这些从节点选取其中一个作为新的主提供服务。集群主节点只提供异步任务进行索引更新操作，从节点根据应用机房部署情况提供索引查询服务。

Redis缓存集群主从部署仍是标配，主节点只提供数据的更新操作，从节点提供前台缓存读服务，实现缓存数据的读写分离，提升了缓存服务的处理能力。当主节点出现故障，选取就近机房的一个从节点作为新主节点提供写服务，并将主从关系进行重新构建。任何一从节点出现故障都可通过内部的配置中心进行一键切换，将故障节点的流量切换到其它的从节点上。

总结

整体数据架构并没有什么高大上的设计，而且整体数据架构方案也是为了解决实际痛点和业务问题而演进过来的。数据存储方案上没有最好的，只有最适合的，因此得根据不同的时期、不同的业务场景去选择合适的设计才是最关键的，大家有什么好的方案和建议可以相互讨论与借鉴，系统的稳定、高性能、高可用才是王道。

文章出处：开涛的博客（公众号ID：kaitao-1234567）

都是套路：高并发系统的降级特技

Thu, 28 Jul 2016 12:03:49 CST

作者简介：

张开涛

京东集团技术研发，2014年加入京东，开发过京东商品详情页、详情页统一服务架构与开发工作，设计并开发了多个亿级访问量系统。

工作之余喜欢写技术博客，有《跟我学 Spring》、《跟我学Spring MVC》、《跟我学Shiro》、《跟我学Nginx+Lua开发》等系列教程。

开篇：

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。之前已经有一些文章介绍过缓存和限流了。本文将详细聊聊降级。

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。

系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。本文将介绍一些笔者在实际工作中遇到的或见到过的一些降级方案供大家参考。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

降级预案

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

降级的类别

降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。

降级的功能点

降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级：

页面降级：在大促或者某些特殊情况下，某些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，以达到丢卒保帅；

页面片段降级：比如商品详情页中的商家部分因为数据错误了，此时需要对其进行降级；

页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级；

服务功能降级：比如渲染商品详情页时需要调用一些不太重要的服务：相关分类、热销榜等，而这些服务在异常情况下直接不获取，即降级即可；

读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；

写降级：比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

爬虫降级：在大促活动时，可以将爬虫流量导向静态页或者返回空数据从而降级保护后端稀缺资源。

降级策略

1、自动开关降级

自动降级是根据系统负载、资源使用情况、SLA等指标进行降级。

超时降级

当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级；

比如商品详情页上有推荐内容/评价，但是推荐内容/评价暂时不展示对用户购物流程不会产生很大的影响；

对于这种服务是可以超时降级的。如果是调用别人的远程服务，和对方定义一个服务响应最大时间，如果超时了则自动降级。

之前总结过一些的文章《使用httpclient必须知道的参数设置及代码写法、存在的风险》和《dbcp配置及jdbc超时设置总结》。在实际场景用一定主要配置好超时时间和超时重试次数和机制。

统计失败次数降级

有时候依赖一些不稳定的API，比如调用外部机票服务，当失败调用次数达到一定阀值自动降级；然后通过异步线程去探测服务是否恢复了，则取消降级。

故障降级

比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。

降级后的处理方案有：

默认值（比如库存服务挂了，返回默认现货）

兜底数据（比如广告挂了，返回提前准备好的一些静态页面）

缓存（之前暂存的一些缓存数据）

限流降级

当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；

降级后的处理方案可以是：

排队页面（将用户导流到排队页面等一会重试）

无货（直接告知用户没货了）

错误页（如活动太火爆了，稍后重试）

2、人工开关降级

在大促期间通过监控发现线上的一些服务存在问题，这个时候需要暂时将这些服务摘掉；

还有有时候通过任务系统调用一些服务，但是服务依赖的数据库可能存在：网卡被打满了、挂掉了或者很多慢查询，此时需要暂停下任务系统让服务方进行处理；

还有发现突然调用量太大，可能需要改变处理方式（比如同步转换为异步）；

此时就可以 使用开关来完成降级。

开关可以存放到配置文件、存放到数据库、存放到Redis/ZooKeeper；如果不是存放在本地，可以定期同步开关数据（比如1秒同步一次）。然后通过判断某个KEY的值来决定是否降级。

另外对于新开发的服务想上线进行灰度测试；但是不太确定该服务的逻辑是否正确，此时就需要设置开关，当新服务有问题可以通过开关切换回老服务。

还有多机房服务，如果某个机房挂掉了，此时需要将一个机房的服务切到另一个机房，此时也可以通过开关完成切换。

还有一些是因为功能问题需要暂时屏蔽掉某些功能，比如商品规格参数数据有问题，数据问题不能用回滚解决，此时需要开关控制降级。

3、读服务降级

对于读服务降级一般采用的策略有：

暂时切换读（降级到读缓存、降级到走静态化）

暂时屏蔽读（屏蔽读入口、屏蔽某个读服务）

在《应用多级缓存模式支撑海量读服务》中曾经介绍过 读服务，即：

接入层缓存→应用层本地缓存→分布式缓存→RPC服务/DB

我们会在接入层、应用层设置开关，当分布式缓存、RPC服务/DB有问题自动降级为不调用。当然这种情况适用于对读一致性要求不高的场景。

页面降级、页面片段降级、页面异步请求降级都是读服务降级，目的是丢卒保帅（比如因为这些服务也要使用核心资源、或者占了带宽影响到核心服务）或者因数据问题暂时屏蔽。

还有一种是页面静态化场景：

动态化降级为静态化：比如平时网站可以走动态化渲染商品详情页，但是到了大促来临之际可以将其切换为静态化来减少对核心资源的占用，而且可以提升性能；其他还有如列表页、首页、频道页都可以这么玩；可以通过一个程序定期的推送静态页到缓存或者生成到磁盘，出问题时直接切过去；

静态化降级为动态化：比如当使用静态化来实现商品详情页架构时，平时使用静态化来提供服务，但是因为特殊原因静态化页面有问题了，需要暂时切换回动态化来保证服务正确性。

以上都保证出问题了有预案，用户还是可以使用网站，不影响用户购物。

4、写服务降级

写服务在大多数场景下是不可降级的，不过可以通过一些迂回战术来解决问题。比如将同步操作转换为异步操作，或者限制写的量/比例。

比如扣减库存一般这样操作：

方案1：

a、扣减DB库存；

b、扣减成功后更新Redis中的库存；

方案2：

a、扣减Redis库存；

b、同步扣减DB库存，如果扣减失败则回滚Redis库存；

前两种方案非常依赖DB，假设此时DB性能跟不上则扣减库存就会遇到问题；因此我们可以想到 方案3：

a、扣减Redis库存：

b、正常同步扣减DB库存，性能扛不住时降级为发送一条扣减DB库存的消息，然后异步进行DB库存扣减实现最终一致即可；

这种方式发送扣减DB库存消息也可能成为瓶颈；这种情况我们可以考虑 方案4：

a、扣减Redis库存；

b、正常同步扣减DB库存，性能扛不住时降级为写扣减DB库存消息到本机，然后本机通过异步进行DB库存扣减来实现最终一致性。

也就是说正常情况可以同步扣减库存，在性能扛不住时降级为异步；另外如果是秒杀场景可以直接降级为异步，从而保护系统。

还有如下单操作可以在大促时暂时降级将下单数据写入Redis，然后等峰值过去了再同步回DB，当然也有更好的解决方案，但是更复杂，不是本文的重点。

还有如用户评价，如果评价量太大，也可以把评价从同步写降级为异步写。当然也可以对评价按钮进行按比例开放（比如一些人的看不到评价操作按钮）。比如评价成功后会发一些奖励，在必要的时候降级同步到异步。

5、多级降级

缓存是离用户最近越高效；而降级是离用户越近越能对系统保护的好。因为业务的复杂性导致越到后端QPS/TPS越低。

页面JS降级开关：主要控制页面功能的降级，在页面中通过JS脚本部署功能降级开关，在适当时机开启/关闭开关；

接入层降级开关：主要控制请求入口的降级，请求进入后会首先进入接入层，在接入层可以配置功能降级开关，可以根据实际情况进行自动/人工降级；

这个可以参考《京东商品详情页服务闭环实践》，尤其在后端应用服务出问题时，通过接入层降级从而给应用服务有足够的时间恢复服务；

应用层降级开关：主要控制业务的降级，在应用中配置相应的功能开关，根据实际业务情况进行自动/人工降级。

总结：

降级能保障系统在大促中活下来，而不是死去，达到丢卒保帅的作用。对用户提供有损服务，总比不服务要好。根据自己的场景设计相应的降级策略，保障系统在危机时刻能通过降级手段平稳度过。

文/张开涛

文章出处：高效运维

如何高效快速地优化MySQL、SQL语句(附源码)

Mon, 26 Sep 2016 10:58:19 CST

作者介绍

韩锋，宜信技术研发中心数据库架构师。精通多种关系型数据库，曾任职于当当网、TOM在线等公司，曾任多家公司首席DBA、数据库架构师等职，多年一线数据库架构、设计、开发经验。著有《SQL优化最佳实践》一书。引言

优化SQL，是DBA常见的工作之一。如何高效、快速地优化一条语句，是每个DBA经常要面对的一个问题。在日常的优化工作中，我发现有很多操作是在优化过程中必不可少的步骤。然而这些步骤重复性的执行，又会耗费DBA很多精力。于是萌发了自己编写小工具，提高优化效率的想法。

那选择何种语言来开发工具呢？

对于一名DBA来说，掌握一门语言配合自己的工作是非常必要的。相对于shell的简单、perl的飘逸，Python是一种严谨的高级语言。其具备上手快、语法简单、扩展丰富、跨平台等多种优点。很多人把它称为一种“胶水”语言，通过大量丰富的类库、模块，可以快速搭建出自己需要的工具。

于是乎，这个小工具就成了我学习Python的第一个作业，我把它称之为“MySQL语句优化辅助工具”。而且从此以后，我深深爱上了Python，并开发了很多数据库相关的小工具，以后有机会介绍给大家。

一、优化手段、步骤

下面在介绍工具使用之前，首先说明下MySQL中语句优化常用的手段、方法及需要注意的问题。这也是大家在日常手工优化中，需要了解掌握的。

1、执行计划 — EXPLAIN命令

执行计划是语句优化的主要切入点，通过执行计划的判读了解语句的执行过程。在执行计划生成方面，MySQL与Oracle明显不同，它不会缓存执行计划，每次都执行“硬解析”。查看执行计划的方法，就是使用EXPLAIN命令。

基本用法

EXPLAIN QUERY

当在一个Select语句前使用关键字EXPLAIN时，MySQL会解释了即将如何运行该Select语句，它显示了表如何连接、连接的顺序等信息。

EXPLAIN EXTENDED QUERY

当使用EXTENDED关键字时，EXPLAIN产生附加信息，可以用SHOW WARNINGS浏览。该信息显示优化器限定SELECT语句中的表和列名，重写并且执行优化规则后SELECT语句是什么样子，并且还可能包括优化过程的其它注解。在MySQL5.0及更新的版本里都可以使用，在MySQL5.1里它有额外增加了一个过滤列(filtered)。

EXPLAIN PARTITIONS QUERY

显示的是查询要访问的数据分片——如果有分片的话。它只能在MySQL5.1及更新的版本里使用。

EXPLAIN FORMAT=JSON (5.6新特性)

另一个格式显示执行计划。可以看到诸如表间关联方式等信息。

输出字段

下面说明一下EXPLAIN输出的字段含义，并由此学习如何判断一个执行计划。

MySQL选定的执行计划中查询的序列号。如果语句里没有子查询等情况，那么整个输出里就只有一个SELECT，这样一来每一行在这个列上都会显示一个1。如果语句中使用了子查询、集合操作、临时表等情况，会给ID列带来很大的复杂性。如上例中，WHERE部分使用了子查询，其id=2的行表示一个关联子查询。

select_type

语句所使用的查询类型。是简单SELECT还是复杂SELECT(如果是后者，显示它属于哪一种复杂类型)。常用有以下几种标记类型。

DEPENDENT SUBQUERY
子查询内层的第一个SELECT，依赖于外部查询的结果集。
DEPENDENT UNION
子查询中的UNION，且为UNION中从第二个SELECT开始的后面所有SELECT，同样依赖于外部查询的结果集。
PRIMARY
子查询中的最外层查询，注意并不是主键查询。
SIMPLE
除子查询或UNION之外的其他查询。
SUBQUERY
子查询内层查询的第一个SELECT，结果不依赖于外部查询结果集。
UNCACHEABLE SUBQUERY
结果集无法缓存的子查询。
UNION
UNION语句中的第二个SELECT开始后面的所有SELECT，第一个SELECT为PRIMARY。
UNION RESULT
UNION中的合并结果。从UNION临时表获取结果的SELECT。
DERIVED
衍生表查询(FROM子句中的子查询)。MySQL会递归执行这些子查询，把结果放在临时表里。在内部，服务器就把当做一个"衍生表"那样来引用，因为临时表就是源自子查询。

table

这一步所访问的数据库中表的名称或者SQL语句指定的一个别名表。这个值可能是表名、表的别名或者一个为查询产生的临时表的标识符，如派生表、子查询或集合。

type

表的访问方式。以下列出了各种不同类型的表连接，依次是从最好的到最差的。

system
系统表，表只有一行记录。这是const表连接类型的一个特例。
const
读常量，最多只有一行匹配的记录。由于只有一行记录，优化程序里该行记录的字段值可以被当作是一个恒定值。const用于在和PRIMARY KEY或UNIQUE索引中有固定值比较的情形。
eq_ref
最多只会有一条匹配结果，一般是通过主键或唯一键索引来访问。从该表中会有一行记录被读取出来以和从前一个表中读取出来的记录做联合。与const类型不同的是，这是最好的连接类型。它用在索引所有部分都用于做连接并且这个索引是一个PRIMARY KEY或UNIQUE类型。eq_ref可以用于在进行"="做比较时检索字段。比较的值可以是固定值或者是表达式，表达示中可以使用表里的字段，它们在读表之前已经准备好了。
ref
JOIN语句中驱动表索引引用的查询。该表中所有符合检索值的记录都会被取出来和从上一个表中取出来的记录作联合。ref用于连接程序使用键的最左前缀或者是该键不是PRIMARY KEY或UNIQUE索引(换句话说，就是连接程序无法根据键值只取得一条记录)的情况。当根据键值只查询到少数几条匹配的记录时，这就是一个不错的连接类型。ref还可以用于检索字段使用"="操作符来比较的时候。
ref_or_null
与ref的唯一区别就是在使用索引引用的查询之外再增加一个空值的查询。这种连接类型类似ref，不同的是MySQL会在检索的时候额外的搜索包含NULL值的记录。这种连接类型的优化是从MySQL 4.1.1开始的，它经常用于子查询。
index_merge
查询中同时使用两个(或更多)索引，然后对索引结果进行合并(merge)，再读取表数据。这种连接类型意味着使用了Index Merge优化方法。
unique_subquery
子查询中的返回结果字段组合是主键或唯一约束。
index_subquery
子查询中的返回结果字段组合是一个索引(或索引组合)，但不是一个主键或唯一索引。这种连接类型类似unique_subquery。它用子查询来代替IN，不过它用于在子查询中没有唯一索引的情况下。
range
索引范围扫描。只有在给定范围的记录才会被取出来，利用索引来取得一条记录。
index
全索引扫描。连接类型跟ALL一样，不同的是它只扫描索引树。它通常会比ALL快点，因为索引文件通常比数据文件小。MySQL在查询的字段知识单独的索引的一部分的情况下使用这种连接类型。
fulltext
全文索引扫描。
all
全表扫描。

possible_keys

该字段是指MySQL在搜索表记录时可能使用哪个索引。如果没有任何索引可以使用，就会显示为null。

查询优化器从possible_keys中所选择使用的索引。key字段显示了MySQL实际上要用的索引。当没有任何索引被用到的时候，这个字段的值就是NULL。

key_len

被选中使用索引的索引键长度。key_len字段显示了MySQL使用索引的长度。当key字段的值为NULL时，索引的长度就是NULL。

列出是通过常量，还是某个表的某个字段来过滤的。ref字段显示了哪些字段或者常量被用来和key配合从表中查询记录出来。

rows

该字段显示了查询优化器通过系统收集的统计信息估算出来的结果集记录条数。

Extra

该字段显示了查询中MySQL的附加信息。

filtered

这个列式在MySQL5.1里新加进去的，当使用EXPLAIN EXTENDED时才会出现。它显示的是针对表里符合某个条件(WHERE子句或联接条件)的记录数的百分比所作的一个悲观估算。

SQL改写

EXPLAIN除了可以显示执行计划外，还可以显示SQL改写。所谓SQL改写，是指MySQL在对SQL语句进行优化前，会基于一些原则进行语句的改写，以方便后面的优化器进行优化生成更优的执行计划。该功能是通过EXPLAIN EXTENDED+SHOW WARNINGS配合使用。下面通过示例说明一下。

从上面示例中，可看到原有语句中的IN子查询被改写成为表间关联的方式。

2、统计信息

查看统计信息也是优化语句中必不可少的一步。通过统计信息可以快速了解对象的存储特征如何。下面说明主要的两类统计信息——表、索引。

表统计信息 — SHOW TABLE STATUS

Name：表名
Engine：表的存储引擎类型(ISAM、MyISAM或InnoDB)
Row_format：行存储格式(Fixed-固定的、Dynamic-动态的或Compressed-压缩的)
Rows：行数量。在某些存储引擎中，例如MyISAM和ISAM他们存储了精确的记录数。不过其他存储引擎中，它可能只是近似值。
Avg_row_length：平均行长度。
Data_length：数据文件的长度。
Max_data_length：数据文件的最大长度。
Index_length：索引文件的长度。
Data_free：已分配但未使用了字节数。
Auto_increment：下一个autoincrement(自动加1)值。
Create_time：表被创造的时间。
Update_time：数据文件最后更新的时间。
Check_time：最后对表运行一个检查的时间。执行mysqlcheck命令后更新，仅对MyISAM有效。
Create_options：额外留给CREATE TABLE的选项。
Comment：当创造表时，使用的注释(或为什么MySQL不能存取表信息的一些信息)。
Version：数据表的'.frm'文件版本号。
Collation：表的字符集和校正字符集。
Checksum：实时的校验和值(如果有的话)。

3、索引统计信息 — SHOW INDEX

Table：表名。
Non_unique：0，如果索引不能包含重复。
Key_name：索引名
Seq_in_index：索引中的列顺序号，从1开始。
Column_name：列名。
Collation：列怎样在索引中被排序。在MySQL中，这可以有值A(升序)或NULL(不排序)。
Cardinality：索引中唯一值的数量。
Sub_part：如果列只是部分被索引，索引字符的数量。当整个字段都做索引了，那么它的值是NULL。
Packed：表示键值是如何压缩的，NULL表示没有压缩。
Null：当字段包括NULL的记录是YES，它的值为，反之则是''。
Index_type：使用了哪种索引算法(有BTREE、FULLTEXT、HASH、RTREE)。
Comment：备注。
系统参数：系统参数也会影响语句的执行效率。查看系统参数，可使用SHOW VARIABLES命令。

参数说明

系统参数很多，下面介绍几个。

sort_buffer_size

排序区大小。其大小直接影响排序使用的算法。如果系统中排序都比较大、内存充足且并发量不是很大的情况，可以适当增加此参数。这个参数是针对单个Thead的。

join_buffer_size

Join操作使用内存区域大小。只有当Join是ALL、index、range或index_merge时使用到Join Buffer。如果join语句较多，可以适当增大join_buffer_size。需要注意到是，这个值针对单个Thread。每个Thread都会自己创建独立的Buffer，而不是整个系统共享的Buffer，不要设置过大而造成系统内存不足。

tmp_table_size

如果内存内的临时表超过该值，MySQL自动将它转换为硬盘上的MyISAM表。如果执行许多高级GROUP BY查询并且有大量内存，则可以增加tmp_table_size的值。

read_buffer_size

读查询操作所能使用的缓冲区大小。这个参数是针对单个Thead的。

4、优化器开关

在MySQL中，还有一些参数是可以用来控制优化器行为的。

参数说明

optimizer_search_depth

这个参数控制优化器在穷举执行计划时的限度。如果查询长时间处于"statistics"状态，可以考虑调低此参数。

optimizer_prune_level

默认是打开的，这让优化器会根据需要扫描的行数来决定是否跳过某些执行计划。

optimizer_switch

这个变量包含了一些开启/关闭优化器特性的标志位。

示例 — 干预优化器行为（ICP特性）

默认情况下，ICP特性是开启的。查看一下优化器行为。

基于二级索引的过滤查询，使用了ICP特性，从Extra中的”Using index condition”可见。如果通过优化器开关，干预优化器行为，又会如何呢？

从Extra可见，ICP特性已经禁用。

5、系统状态（SHOW STATUS）

MySQL中也内置了一些状态，通过这些状态变量也可反映出语句执行的一些情况，方便定位问题。手工执行的话，可以在执行语句的前后分别执行SHOW STATUS命令，查看状态的变化。当然，因状态变量很多，对比起来不太方便，后面我介绍的小工具，可以解决这个问题。

状态变量

状态变量很多，这里介绍几个。

Sort_merge_passes

排序算法已经执行的合并的数量。如果这个变量值较大，应考虑增加sort_buffer_size系统变量的值。

Sort_range

在范围内执行的排序的数量。

Sort_rows

已经排序的行数。

Sort_scan

通过扫描表完成的排序的数量。

Handler_read_first

索引中第一条被读的次数。读取索引头的次数，如果这个值很高，说明全索引扫描很多。

Handler_read_key

根据键读一行的请求数。如果较高，说明查询和表的索引正确。

Handler_read_next

按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。

Handler_read_prev

按照键顺序读前一行的请求数。

Handler_read_rnd

根据固定位置读一行的请求数。如果执行大量查询并需要对结果进行排序该值较高。则可能使用了大量需要MySQL扫描整个表的查询或连接没有正确使用键。

Handler_read_rnd_next

在数据文件中读下一行的请求数。如果正进行大量的表扫描，该值较高。通常说明表索引不正确或写入的查询没有利用索引。

6、SQL性能分析器（Query Profiler）

MySQL的Query Profiler是一个使用非常方便的Query诊断分析工具，通过该工具可以获取一条Query在整个执行过程中多种资源的消耗情况，如CPU、IO、IPC、SWAP等，以及发生的PAGE FAULTS、CONTEXT SWITCHE等，同时还能得到该Query执行过程中的MySQL所调用的各个函数在源文件中的位置。

使用方法

开启

mysql> select @@profiling;

mysql> set profiling=1;

默认情况下profiling的值为0表示MySQL SQL Profiler处于OFF状态，开启SQL性能分析器后profiling的值为1。

执行SQL语句

mysql> select count(*) from t1;

获取概要信息

使用"show profile"命令获取当前系统中保存的多个Query的profile的概要信息。

mysql> show profiles;

+----------+------------+-----------------------+

| Query_ID | Duration | Query |

+----------+------------+-----------------------+

| 1 | 0.00039300 | select count(*) from t1 |

+----------+------------+-----------------------+

针对单个Query获取详细的profile信息

在获取概要信息之后，就可以根据概要信息的Query_ID来获取某个Query的执行过程中详细的profile信息。

mysql> show profile for query 1;

mysql> show profile cpu,block io for query 1;

二、工具说明

前面谈到了多种手段，对于SQL语句的调优都有所帮助。通过下面这个小工具，可以自动调用命令将上面这些内容一次性推给DBA，大大加速优化的过程。

1、准备条件

模块 - MySQLDB
模块 - sqlparse
Python版本 = 2.7.3 (2.6.x版本应该也没问题，3.x版本没测试)

2、调用方法

python mysql_tuning.py -p tuning_sql.ini -s 'select xxx' 参数说明

-p 指定配置文件名称

-s 指定SQL语句

3、配置文件

共分两节信息，分别是[database]描述数据库连接信息，[option]运行配置信息。

[database] server_ip = 127.0.0.1

db_user = testuser

db_pwd = testpwd

db_name = test

[option] sys_parm = ON //是否显示系统参数

sql_plan = ON //是否显示执行计划

obj_stat = ON //是否显示相关对象(表、索引)统计信息

ses_status = ON //是否显示运行前后状态信息(激活后会真实执行SQL)

sql_profile = ON //是否显示PROFILE跟踪信息(激活后会真实执行SQL)

4、输出说明

标题部分

包含运行数据库的地址信息及数据版本信息。

原始SQL

用户执行输入的SQL，这部分主要是为了后续对比SQL改写时使用。语句显示时使用了格式化。

系统级参数

脚本选择显示了部分与SQL性能相关的参数。这部分是写死在代码中的，如需扩展需要修改脚本。

优化器开关

下面是和优化器相关的一些参数，通过调整这些参数可以人为干预优化器行为。

执行计划

就是调用explain extended的输出结果。如果结果过长，可能出现显示串行的问题(暂时未解决)。

优化器改写后的SQL

通过这里可判断优化器是否对SQL进行了某种优化(例如子查询的处理)。

统计信息

在SQL语句中所有涉及到的表及其索引的统计信息都会在这里显示出来。

运行状态信息

在会话级别对比了执行前后的状态(SHOW STATUS)，并将出现变化的部分显示出来。需要注意的是，因为收集状态数据是采用SELECT方式，会造成个别指标的误差(例如Com_select)。

PROFILE详细信息

调用SHOW PROFILE得到的详细信息。

PROFILE汇总信息

根据PROFILE的资源消耗情况，显示不同阶段消耗对比情况(TOP N)，直观显示"瓶颈"所在。

源码文件下载 http://pan.baidu.com/s/1slF3zS5

如何挖掘Nginx日志中隐藏的金矿？

Tue, 13 Sep 2016 11:43:30 CST

对很多开发运维人员来说，Nginx日志文件在被删除前可能都不会看上一眼。但实际上，Nginx隐藏了相当丰富的信息，或许其中便蕴含着未知的金矿等你挖掘！

Nginx（读作Engine-X）是现在最流行的负载均衡和反向代理服务器之一。如果你是一名中小微型网站的开发运维人员，很可能像我们一样，仅Nginx每天就会产生上百M甚至数以十G的日志文件。如果没有出什么错误，在被logrotate定期分割并滚动删除以前，这些日志文件可能都不会被看上一眼。

实际上，Nginx日志文件可以记录的信息相当丰富，而且格式可以定制，考虑到`$time_local`请求时间字段几乎必有，这是一个典型的基于文件的时间序列数据库。Nginx日志被删除以前，或许我们可以想想，其中是否蕴含着未知的金矿等待挖掘？

请求访问分析

Nginx中的每条记录是一个单独的请求，可能是某个页面或静态资源的访问，也可能是某个API的调用。通过几条简单的命令，了解一下系统的访问压力：

// 请求总数     
 less main.log | wc -l   
 1080577         
 // 平均每秒的请求数    
less main.log | awk '{sec=substr($4,2,20);reqs++;reqsBySec[sec]++;} END{print reqs/length(reqsBySec)}'    14.0963          
// 峰值每秒请求数   
 less main.log | awk '{sec=substr($4,2,20);requests[sec]++;} END{for(s in requests){printf("%s %s\n", requests[s],s)}}' | sort -nr | head -n 3    
Page Visits  Response Size  Time Spent/req  Moment    
182 10/Apr/2016:12:53:20      
161 10/Apr/2016:12:54:53    
160 10/Apr/2016:10:47:23

请求总数、平均每秒请求数、峰值请求数，可以大体了解系统压力，作为系统扩容、性能及压力测试时的直接参考。查询特定的URL，比如下单页面，了解每天的下单状况，导出CSV格式，或使用可视化工具，更直观地了解一段时间内的请求、下单数据：

备注：本文使用awk命令处理，与Nginx日志的格式有关，如果您格式不同，请酌情修改命令。本文所用的Nginx日志格式：

$remote_addr - $remote_user [$time_local] "$request" 
$status  $body_bytes_sent $request_time $upstream_response_time 
$upstream_addr "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';

示例：

42.100.52.XX - - [10/Apr/2016:07:29:58 +0800] "GET /index
 HTTP/1.1" 200 7206 0.092 0.092 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 
7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257" "-"

流量速率分析

Nginx日志如果开启，除了请求时间，一般会包含响应时间、页面尺寸等字段，据此很容易计算出网络流量、速率。

等等，你可能会有疑问，上面的请求访问分析，这里的流量速率分析，按时间轴画出来，不就是监控系统干的事儿吗，何苦这么麻烦查询Nginx日志？

的确如此，监控系统提供了更实时、更直观的方式。而Nginx日志文件的原始数据，可以从不同维度分析，使用得当，会如大浪淘沙般，发现属于我们的金子。

对一般网站来说，带宽是最珍贵的资源，可能一不小心，某些资源如文件、图片就占用了大量的带宽，执行命令检查一下：

less static.log | awk 'url=$7; requests[url]++;bytes[url]+=$10} 
END{for(url in requests){printf("%sMB %sKB/req %s %s\n", bytes[url] / 
1024 / 1024, bytes[url] /requests[url] / 1024, requests[url], url)}}' | sort -nr | head -n 15

备注：Nginx配置文件中日志格式使用了$body_sent_size，指HTTP响应体的大小，如果想查看整个响应的大小，应该使用变量$sent_size。

不出意外，静态资源、图片类（如果还没有放CDN）占据榜首，自然也是优化的重点：是否可以再压缩，某些页面中是否可以用缩略图片代替等。

与之相比，后台调用、API接口等通常消耗更多的CPU资源，按照一贯“先衡量、再优化”的思路，可以根据响应时间大体了解某个URL占用的CPU时间：

less main.log | awk '{url=$7; times[url]++} END{for(url in times){printf("%s %s\n", times[url], url)}}' | sort -nr | more` 

 40404 /page/a?from=index   

 1074 /categories/food   

 572 /api/orders/1234.json

不对，发现一个问题：由于拥有服务号、App、PC浏览器等多种前端，并且使用不规范，URL的格式可能乱七八糟。比如`/page/a`页面，有的带有.html后缀，有的未带，有的请求路径则带有参数；分类页/categories/food带有`slug`等信息；订单、详情或个人中心的URL路径则有`ID`等标记...。

借助sed命令，通过三个方法对URL格式进行归一化处理：去掉所有的参数；去掉`.html`及`.json`后缀；把数字替换为`*`。可以得到更准确的统计结果，：

less main.log | awk '{print $7}' |sed -re 's/(.*)\?.*/\1/g' -e

 's/(.*)\..*/\1/g' -e 's:/[0-9]+:/*:g' | awk '{requests[$1]++;time[$1] 

+=$2} END{for(url in requests){printf("%smin %ss/req %s %s\n", time

 [url] / 60, time[url] /requests[url], requests[url], url)}}' | sort -nr | head -n 50

备注：这里使用了扩展正则表达式，GNU sed的参数为-r，BSD sed的参数为-E。

那些累计占用了更多响应时间的请求，通常也耗用了更多的CPU时间，是性能优化重点照顾的对象。

慢查询分析

“服务号刚推送了文章，有用户反映点开很慢”，你刚端起桌子上的水杯，就听到产品经理的大嗓门从办公室角落呼啸而来。“用户用的什么网络”，你一边问着，一边打开服务号亲自尝试一下。是用户网络环境不好，还是后台系统有了访问压力？是这一个用户慢，还是很多用户都慢？你一边脑子里在翻腾，一边又打开命令行去查看日志。

与PC浏览器相比，微信服务号在网络环境、页面渲染上有较大的掣肘，在缓存策略上也不如APP自如，有时会遇到诡异的问题。如果手里恰好有Nginx日志，能做点什么呢？

考虑一下MySQL数据库，可以打开慢查询功能，定期查找并优化慢查询，与此类似，Nginx日志中的响应时间，不相当于自带慢查询功能嘛。利用这一特性，我们分步进行慢查询分析：

第一步：是不是用户的网络状况不好？根据既往的经验，如果只有少量的请求较慢，而前后其他IP的请求都较快，通常是用户手机或网络状况不佳引起的。最简单的方法，统计慢查询所占比例：

less main.log | awk -v limit=2 '{min=substr($4,2,17);reqs[min] 

++;if($11>limit){slowReqs[min]++}} END{for(m in slowReqs){printf("%s %s %s%s %s\n", m, slowReqs[m]/reqs[m] * 100, "%", slowReqs[m], reqs [m])}}' | more    

10/Apr/2016:12:51 0.367% 7 1905   

 10/Apr/2016:12:52 0.638% 12 1882    

10/Apr/2016:12:53 0.548% 14 2554

慢查询所占比例极低，再根据用户手机型号、访问时间、访问页面等信息看能否定位到指定的请求，结合前后不同用户的请求，就可以确定是否用户的网络状况不好了。

第二步：是不是应用系统的瓶颈？对比应用服务器的返回时间($upstream_response_time字段），与Nginx服务器的处理时间($request_time字段)，先快速排查是否某一台服务器抽风。

我们遇到过类似问题，平均响应时间90ms，还算正常，但某台服务器明显变慢，平均响应时间达到了200ms，影响了部分用户的访问体验。

less main.log | awk '{upServer=$13;upTime=$12;if(upServer == "-"){upServer="Nginx"};if(upTime == "-"){upTime=0};upTimes[upServer] +=upTime;count[upServer]++;totalCount++;} END{for(server in upTimes) {printf("%s %s%s %ss %s\n", count[server], count[server]/totalCount * 100, "%", upTimes[server]/count[server], server)}}' | sort -nr

不幸，市场部此次推广活动，访问压力增大，所有服务器都在变慢，更可能是应用系统的性能达到了瓶颈。如果此时带宽都没跑满，在硬件扩容之前，考虑优化重点API、缓存、静态化策略吧，达到一个基本的要求：“优化系统，让瓶颈落到带宽上”。

第三步：应用系统没有瓶颈，是带宽的问题？快速查看一下每秒的流量：

less main.log | awk '{second=substr($4,2,20);bytes[second]+=$10;} END{for(s in bytes){printf("%sKB %s\n", bytes[s]/1024, s)}}' | more`    1949.95KB 10/Apr/2016:12:53:15    2819.1KB 10/Apr/2016:12:53:16    3463.64KB 10/Apr/2016:12:53:17    3419.21KB 10/Apr/2016:12:53:18    2851.37KB 10/Apr/2016:12:53:19

峰值带宽接近出口带宽最大值了，幸福的烦恼，利用前面介绍的不同URL的带宽统计，做定向优化，或者加带宽吧。

还能做哪些优化？

SEO团队抱怨优化了那么久，为什么页面索引量和排名上不去。打印出不同爬虫的请求频次（$http_user_agent），或者查看某个特定的页面，最近有没有被爬虫爬过：

less main.log | egrep 'spider|bot' | awk '{name=$17;if(index ($15,"spider")>0){name=$15};spiders[name]++} END{for(name in spiders) {printf("%s %s\n",spiders[name], name)}}' | sort -nr

数据告诉我们，页面索引量上不去，不一定是某个爬虫未检索到页面，更多的是其他原因。

市场团队要上一个新品并且做促销活动，你建议避开周一周五，因为周三周四的转化率更高：

周三、周四的转换率比周末高不少，可能跟平台的发货周期有关，客户周三四下单，希望周末就能收到货，开始快乐的周末。你猜测到用户的心理和期望，连数据一起交市场品团队，期待更好地改善。

这样的例子可以有很多。事实上，上述分析限于Nginx日志，如果有系统日志，并且日志格式定义良好，可以做的事情远不止于此：这是一个时间序列数据库，可以查询IT系统的运行情况，可以分析营销活动的效果，也可以预测业务数据的趋势；这是一个比较小但够用的大数据源，运用你学会的大数据分析方法，也可以像滴滴那样，分并预测不同天气、时间段下不同地区的车辆供需，并作出优化。

几点建议

规范日志格式。这是很多团队容易忽略的地方，有时候多一个空格会让日志分析的复杂度大为增加。
无论如何，使用时间戳字段。以时间序列的方式看待日志文件，这也是很多公司把系统日志直接写入到时间序列数据库的原因；
如有可能，记录以下字段：用户（或者客户端）标识、单次请求标识、应用标识（如果单次请求会走到多个应用）。能够方便地查出用户链路、请求链路，是排查错误请求、分析用户行为的基础；
关注写的操作。就像业务建模时，需要特别关注具有时标性、状态会发生改变的模型一样，任何写的操作，都应记录到日志系统中。万一某个业务出错，不但可以通过业务模型复演，也可以通过日志系统复演。
规范URL格式。这一点同样容易遭到忽略，商品详情页面要不要添加"?from=XXX"来源参数？支付页面采用路径标记“payment/alipay”，还是参数标记“/payment?type=alipay”更合适？区别细微但影响不可忽略。

技术团队应该像对待协议一样对待这些规范。仔细定义并严格遵守，相当于拿到了金矿的钥匙。

还需要寻找一个合适的日志分析工具，基于Python、Go、Lua，都有免费的日志分析工具可供使用；想更轻量，准备几条常用的shell脚本，比如作者整理了一些到GitHub的这个项目上（https://github.com/aqingsao/nana）；或者基于ELK技术栈，把Nginx访问日志、业务日志统一存储，并通过Kibana进行不同维度的聚合分析，都是不错的办法。

或许你早就使用Nginx日志了，你是怎么使用的，有什么好的方法呢，欢迎一起交流。

文章来源：InfoQ

作者：张晓庆

基于Lambda架构的股票市场事件处理引擎实践

Mon, 29 Aug 2016 20:30:02 CST

CEP（Complex Event Processing）是证券行业很多业务应用的重要支撑技术。CEP的概念本身并不新鲜，相关技术已经被运用超过15年以上，但是证券界肯定是运用CEP技术最为充分、最为前沿的行业之一，从算法交易（algorithmic trading）、风险管理（risk management）、关键时刻管理（Moment of Truth - MOT）、委托与流动性分析（order and liquidity analysis）到量化交易（quantitative trading）乃至向投资者推送投资信号（signal generation）等等，不一而足。

CEP技术通常与Time-series Database（时序数据库）结合，最理想的解决方案是CEP技术平台向应用提供一个历史序列（historical time-series）与实时序列（real-time series）无差异融合的数据流连续体（continuum）- 对于证券类应用而言，昨天、上周、上个月的数据不过是当下此刻数据的延续，而处理算法却是无边际的 – 只要开发者能构想出场景与模型。

广发证券的IT研发团队，一直关注Storm、Spark、Flink等流式计算的开源技术，也经历了传统Lambda架构的技术演进，在Kappa架构的技术尚未成熟之际，团队针对证券行业的技术现状与特点，采用改良的Lambda架构实现了一个CEP引擎，本文介绍了此引擎的架构并分享了一些股票业务较为有趣的应用场景，以飨同好。

随着移动互联和物联网的到来，大数据迎来了高速和蓬勃发展时期。一方面，移动互联和物联网产生的大量数据为孕育大数据技术提供了肥沃的土壤；一方面，各个公司为了应对大数据量的挑战，也急切的需要大数据技术解决生产实践中的问题。短时间内各种技术层出不穷，在这个过程中Hadoop脱颖而出，并营造了一个丰富的生态圈。虽然大数据一提起Hadoop，好像有点老生常谈，甚至觉得这个技术已经过时了，但是不能否认的是Hadoop的出现确实有非凡的意义。不管是它分布式处理数据的理念，还是高可用、容错的处理都值得好好借鉴和学习。

刚开始，大家可能都被各种分布式技术、思想所吸引，一头栽进去，掉进了技术的漩涡，不能自拔。一方面大数据处理技术和系统确实复杂、繁琐；另一方面大数据生态不断的推陈出新，新技术和新理念层出不穷，确实让人目不暇接。如果想要把生态圈中各个组件玩精通确实不是件容易的事情。本人一开始也是深陷其中，皓首穷经不能自拔。但腾出时间，整理心绪，回头反顾，突然有种释然之感。大数据并没有大家想象的那么神秘莫测与复杂，从技术角度看无非是解决大数据量的采集、计算、展示的问题。

因此本文参考Lambda/Kappa架构理念，提出了一种 有行业针对性的实现方法。尽量让系统层面更简单，技术更同构，初衷在让大家聚焦在大数据业务应用上来，从而真正让大数据发挥它应有的价值。

1、背景

Lambda架构是由Storm的作者Nathan Marz 在BackType和Twitter多年进行分布式大数据系统的经验总结提炼而成，用数学表达式可以表示如下：

batch view = function(all data)
realtime view = function(realtime view,new data)
query = function(batch view .realtime view)

逻辑架构图如下：

从图上可以看出，Lambda架构主要分为三层：批处理层，加速层和服务层。它整合了离线计算和实时计算，融合了不可变性（immutable），读写分离和复杂性隔离等一系列架构原则设计而成，是一个满足大数据系统关键特性的架构。Nathan Marz认为大数据系统应该具有以下八个特性，Lambda都具备它们分别是：

Robustness and fault tolerance（鲁棒性和容错性）
Low latency reads and updates（读和更新低延时）
Scalability（可伸缩）
Generalization（通用性）
Extensibility（可扩展）
Ad hoc queries（可即席查询）
Minimal maintenance（易运维）
Debuggability（可调试）

由于Lambda架构的数据是不可变的（immutable），因此带来的好处也是显而易见的：

Human-fault tolerance（对人为的容错性）：数据流水被按时序记录下来，而且数据只写一次，不做更改，而不像RDBMS只是保留最后的状态。因此不会丢失数据信息。即使平台升级或者计算程序中不小心出现Bug，修复Bug后重新计算就好。强调了数据的重新计算问题，这个特性对一个生产的数据平台来说是十分重要的。
Simplicity（简易性）：可变的数据模型一般要求数据能必须被索引，以便于数据可被再次被检索到和可以被更新。但是不变的数据模型相对来说就很简单了，只是一味的追加新数据即可。大大简化了系统的复杂度。

但是Lambda也有自身的局限性，举个例子：在大数据量的情况下，要即席查询过去24小时某个网站的pv数。根据前面的数学表达式，Lambda架构需要实现三部分程序，一部分程序是批处理程序，比如可能用Hive或者MapReduce批量计算最近23.5个小时pv数，一部分程序是Storm或Spark Streaming流式计算程序，计算0.5个小时内的pv数，然后还需要一个服务程序将这两部分结果进行合并，返回最终结果。因此Lambda架构包含固有的开发和运维的复杂性。

因为以上的缺陷，Linkedin的Jay Kreps在2014年7月2日在O’reilly《Questioning the Lambda Architecture》提出了Kappa架构，如下图：

Kappa在Lambda做的最大的改进是用同一套实时计算框架代替了Lambda的批处理层，这样做的好处是一套代码或者一套技术栈可以解决一个问题。它的做法是这样的：

用Kafka做持久层，根据需求需要，用Kafka保留需要重新计算的历史数据长度，比如计算的时候可能用30天的数据，那就配置Kafka的值，让它保留最近30天的数据。
当你程序因为升级或者修复了缺陷，需要重新计算的时候，就再启一个流式计算程序，从你所需的Offset开始计算，并将结果输入到一个新的表里。
当这个流式计算程序追平第一个程序的时候，将应用切换到第二个程序的输出上。
停止第一个程序，删除第一个程序的输出结果表。

这样相当于用同一套计算框架和代码解决了Lambda架构中开发和运维比较复杂的问题。当然如果数据量很大的情况下，可以增加流式计算程序的并发度来解决速度的问题。

2、广发证券Lambda架构的实现

由于金融行业在业务上受限于T+1交易，在技术上严重依赖关系型数据库（特别是Oracle）。在很多场景下，数据并不是以流的形式存在的，而且数据的更新频率也并不是很实时。比如为了做技术面分析的行情数据，大多数只是使用收盘价和历史收盘价（快照数据）作为输入，来计算各类指标，产生买卖点信号。

因此这是一个典型的批处理的场景。另一方面，比如量化交易场景，很多实时的信号又是稍纵即逝，只有够实时才存在套利的空间，而且回测和实盘模拟又是典型的流处理。鉴于以上金融行业特有的场景，我们实现了我们自己的架构（GF-Lambda），它介于Lambda和Kappa之间。一方面能够满足我们处理数据的需求；一方面又可以达到技术上的同构，减少开发运维成本。根据对数据实时性要求，将整个计算部分分为三类：

Spark SQL：代替MapReduce或者Hive的功能，实现数据的批量预处理；
Spark Streaming：近实时高吞吐的mini batching数据处理功能；
Storm：完成实时的流式数据处理；

GF-Lambda的优势如下：

在PipeLine的驱动方面，采用Airbnb开源的Airflow，Airflow使用脚本语言来实现整个PipeLine的定义，而且任务实例也是动态生成的；相比Oozie和Azkaban采用标记语言来完成PipeLine的定义，Airflow的优势是显而易见的，例如：
整个data flow采用脚本编写，便于配置管理和升级。而Oozie只能使用XML定义，升级迁移成本较大。

触发方式灵活，整个PipeLine可以动态生成，切实的做到了“analytics as a service”或者 “analysis automation”。
另外一个与Lambda或者Kappa最大的不同之处是我们采用了Redis作为缓存来存储各个计算服务的状态；虽然Spark和Storm都有Checkpoint机制，但是CheckPoint会影响到程序复杂度和性能，并且以上两种技术的CheckPoint机制并不是很完善。通过Redis和Kafka的Offset机制，不仅可以做到无状态的计算服务，而且即使升级或者系统故障，数据的可用性也不会受到影响。
整个batch layer采用Spark SQL，使用Spark SQL的好处是能做到密集计算的后移。由于历史原因，券商Oracle等关系型数据库使用比较多，而且在开市期间数据库压力也比较大，此处的Spark SQL只是不断的从Oracle批量加载数据（除了Filter基本在Oracle上做任何计算）或者主动的通过Oracle日志旁录数据，对数据库压力较小，同时又能达到数据准实时性的要求；另外所有的计算都后置到Yarn集群上进行，不仅利于程序的运维，也利于资源的有效管控和伸缩。架构实现如下图所示：

3、应用场景

CEP在证券市场的应用的有非常多，为了读者更好的理解上述技术架构的设计，在此介绍几个典型应用场景。

1）自选股到价和涨跌幅提醒

自选股到价和涨跌幅提醒是股票交易软件的一个基础服务器，目的在于方便用户简单、及时的盯盘。其中我们使用MongoDB来存储用户的个性化设置信息，以便各类应用可以灵活的定制自身的Schema。在功能上主要包括以下几种：

股价高于设定值提醒。
股价低于设定值提醒。
涨幅高于设定值提醒。
一分钟、五分钟涨幅高于设定值提醒。
跌幅高于设定值提醒。
一分钟、五分钟跌幅高于设定值提醒。

主要的挑战在于大数据量的实时计算，而采用GF-Lambda可以轻松解决这个问题。数据处理流程如下：

首先从Kafka订阅实时行情数据并进行解析，转化成RDD对象，然后再衍生出Key（market+stockCode），同时从Mongo增量加载用户自选股预警设置数据，然后将这两份数据进行一个Join，再分片对同一个Key的两个对象做一个Filter，产生出预警信息，并进行各个终端渠道推送。

2）自选股实时资讯

实时资讯对各类交易用户来说是非常重要的，特别是和自身严重相关的自选股实时资讯。一个公告、重大事项或者关键新闻的出现可能会影响到用户的投资回报，因此这类事件越实时，对用户来说价值就越大。

在GF-Lambda平台上，自选股实时资讯主要分为两部分：实时资讯的采集及预处理（适配）、资讯信息与用户信息的撮合。整个处理流程如下图所示：

在上图分割线左侧是实时资讯的预处理部分，首先使用Spark JDBC接口从Oracle数据库加载数据到Spark，形成DataFrame，再使用Spark SQL的高级API做数据的预处理（此处主要做表之间的关联和过滤），最后将每个Partition上的数据转化成协议要求的格式，写入Kafka中等待下游消费。

左侧数据ETL的过程是完全由Airflow来进行驱动调度的，而且每次处理完就将状态cache到Redis中，以便下次增量处理。在上图的右侧则是与用户强相关的业务逻辑，将用户配置的信息与实时资讯信息进行撮合匹配，根据用户设置的偏好来产生推送事件。

此处用Kafka来做数据间的解耦，好处是不言而喻的。首先是保证了消息之间的灵活性，因为左侧部分产生的事件是一个基础公共事件，而右侧才是一个与业务紧密耦合的逻辑事件。基础公共事件只有事件的基础属性，是可以被很多业务同时订阅使用的。

其次从技术角度讲左侧是一个类似批处理的过程，而右侧是一个流处理的过程，中间通过Kafka做一个转换与对接。这个应用其实是很具有代表性的，因为在大部分情况下，数据源并不是以流的形式存在，更新的频率也并不是那么实时，所以大多数情况下都会涉及到batch layer与speed layer之间的转换对接。

3）资金流选股策略

上面两个应用相对来说处理流程比较简单，以下这个case是一个业务
稍微繁琐的CEP应用-资金流策略交易模型，该模型使用资金流流向来判断股票在未来一段时间的涨跌情况。它基于这样一个假设，如果是资金流入的股票，则股价在未来一段时间上涨是大概率事件；如果是资金流出的股票，则股价在未来一段时间下跌是大概率事件。那么我们可以基于这个假设来构建我们的策略交易模型。如下图所示，这个模型主要分为三部分：

1）个股资金流指标的实时计算

由于涉及到一些业务术语，这里先做一个简单的介绍。

资金流是一种反映股票供求关系的指标，它的定义如下：证券价格在约定的时间段中处于上升状态时产生的成交额是推动指数上涨的力量，这部分成交额被定义为资金流入；证券价格在约定的时间段中下跌时的成交额是推动指数下跌的力量，这部分成交额被定义为资金流出；若证券价格在约定的时间段前后没有发生变化，则这段时间中的成交额不计入资金流量。当天资金流入和流出的差额可以认为是该证券当天买卖两种力量相抵之后，推动价格变化的净作用量，被定义为当天资金净流量。数量化定义如下：

其中，Volume为成交量，为i时刻收盘价，为上一时刻收盘价。

严格意义上讲，每一个买单必须有一个相应的卖单，因此真实的资金流入无法准确的计算，只能通过其他替代方法来区分资金的流入和流出，通过高频数据，将每笔交易按照驱动股价上涨和下跌的差异，确定为资金的流入或流出，最终汇聚成一天的资金流净额数据。根据业界开发的CMSMF指标，采用高频实时数据进行资金流测算，主要出于以下两方面考虑：一是采用高频数据进行测算，可以尽可能反映真实的市场信息；二是采取报价（最近买价、卖价）作为比较基准，成交价大于等于上期最优卖价视为流入，成交价小于等于上期最优买价视为流出。

除了资金的流入、流出、净额，还有一系列衍生指标，比如根据流通股本数多少衍生出的大、中、小单流入、流出、净额，及资金流信息含量（IC）、资金流强度（MFP），资金流杠杆倍数（MFP），在这里就不一一介绍。

从技术角度讲，第一部分我们通过订阅实时行情信息，开始计算当天从开市到各个时刻点的资金流入、流出的累计值，及衍生指标，并将这些指标计算完成后重新写回到Kafka进行存储，方便下游消费。因此第一部分完全是一个大数据量的实时流处理应用，属于Lambda的speed layer。

2）买卖信号量的产生及交易

第二部分在业务上属于模型层，即根据当前实时资金流指标信息，构建自己的策略模型，输出买卖信号。比如以一个简单的策略模型为例,如果同时满足以下三个条件产生买的信号。反之，产生卖的信号：

(大单资金流入-大单资金流出>0) && (中单资金流入-中单资金流出>0)
大单的资金流信息含量>50%
大单的资金流强度>20%

在技术上，这个应用也属于Lambda的 speed layer，通过订阅Kafka中的资金流指标，根据上面简单的模型，不断的判断是否要买或者卖，并调用接口发起买卖委托指令，最后根据回报结果操作持仓表或者成交表。（注意此处在业务上只是以简单的模型举例，没有涉及到更多的细节）

3）持仓盈亏实时追踪及交易

第三部分在业务上主要是准实时的盈亏计算。在技术层面，属于Lambda 的batch layer。通过订阅实时行情和加载持仓表/成交表，实时计算用户的盈亏情况。当然此处还有一些简单的止损策略，也可以根据盈利情况，发起卖委托指令，并操作持仓表和成交表。最后将盈利情况报给服务层，进行展示或者提供回调接口。详细的处理流程如下图所示：

总结

正如文章前面强调的一样，写这篇文章的初衷是希望大家从大数据丰富的生态中解放出来，与业务深度的跨界融合，从而开发出更多具有价值的大数据应用，真正发挥大数据应有的价值。这和Lambda架构的作者Nathan Marz的理念也是十分吻合的，记得他还在BackType工作的时候，他们的团队才五个人，却开发了一个社会化媒体分析产品——在100TB的数据上提供各种丰富的实时分析，同时这个小的团队还负责上百台机器的集群的部署、运维和监控。

当他向别人展示产品的时候，很多人都很震惊他们只有五个人。经常有人问他：“How can so few people do so much?”。他的回答是：“It’s not what we’re doing, but what we’re not doing.”通过使用Lambda架构，他们避免了传统大数据架构的复杂性，从而产出变得非常显著。

在五花八门的大数据技术层出不穷的当下，Marz的理念更加重要。我们一方面需要与时俱进关注最新的技术进步 – 因为新技术的出现可能反过来让以前没有考虑过或者不敢想的应用场景变成可能，但另一方面更重要的是，大数据技术的合理运用需要建立在对行业领域知识深刻理解的基础上。大数据是金融科技的核心支撑技术之一，我们将持续关注最前沿的大数据技术与架构理念，持续优化最符合金融行业特点的解决方案，构建能放飞业务专家专业创新能力的技术平台。

作者介绍

邓昌甫，毕业于中山大学，广发证券IT研发工程师，一直从事大数据平台的架构、及大数据应用的开发、运维和敏捷相关工具的引入和最佳实践的推广（Git/Jenkins/Gerrit/Zenoss）。

文章出处：聊聊架构（订阅号ID:archtime）

MaxScale：实现MySQL读写分离与负载均衡的中间件利器

Tue, 23 Aug 2016 11:54:52 CST

1、 MaxScale 是干什么的？

配置好了 MySQL的主从复制结构后，我们希望实现读写分离，把读操作分散到从服务器中，并且对多个从服务器能实现负载均衡。

读写分离和负载均衡是MySQL集群的基础需求，MaxScale 就可以帮着我们方便的实现这些功能。

2、MaxScale 的基础构成

MaxScale 是MySQL的兄弟公司 MariaDB 开发的，现在已经发展得非常成熟。MaxScale 是插件式结构，允许用户开发适合自己的插件。

MaxScale 目前提供的插件功能分为5类：

认证插件

提供了登录认证功能，MaxScale 会读取并缓存数据库中 user 表中的信息，当有连接进来时，先从缓存信息中进行验证，如果没有此用户，会从后端数据库中更新信息，再次进行验证
协议插件

包括客户端连接协议，和连接数据库的协议
路由插件

决定如何把客户端的请求转发给后端数据库服务器，读写分离和负载均衡的功能就是由这个模块实现的
监控插件

对各个数据库服务器进行监控，例如发现某个数据库服务器响应很慢，那么就不向其转发请求了
日志和过滤插件

提供简单的数据库防火墙功能，可以对SQL进行过滤和容错

3、 MaxScale 的安装使用

例如有 3 台数据库服务器，是一主二从的结构。

过程概述

（1）配置好集群环境

（2）下载安装 MaxScale

（3）配置 MaxScale，添加各数据库信息

（4）启动 MaxScale，查看是否正确连接数据库

（5）客户端连接 MaxScale，进行测试

详细过程

（1）配置一主二从的集群环境

准备3台服务器，安装MySQL，配置一主二从的复制结构。

（2）安装 MaxScale

最好在另一台服务器上安装，如果资源不足，可以和某个MySQL放在一起。

MaxScale 的下载地址：https://downloads.mariadb.com/files/MaxScale

根据自己的服务器选择合适的安装包。

以 centos 7 为例安装步骤如下：

yum install libaio.x86_64 libaio-devel.x86_64 novacom-server.x86_64 libedit -yrpm -ivh maxscale-1.4.3-1.centos.7.x86_64.rpm

（3）配置 MaxScale

在开始配置之前，需要在 master 中为 MaxScale 创建两个用户，用于监控模块和路由模块。

创建监控用户

mysql> create user scalemon@'%' identified by "111111";mysql> grant replication slave, replication client on *.* to scalemon@'%';

创建路由用户

mysql> create user maxscale@'%' identified by "111111";mysql> grant select on mysql.* to maxscale@'%';

用户创建完成后，开始配置

vi /etc/maxscale.cnf

找到 [server1] 部分，修改其中的 address 和 port，指向 master 的 IP 和端口。

复制2次 [server1] 的整块儿内容，改为 [server2] 与 [server3]，同样修改其中的 address 和 port，分别指向 slave1 和 slave2：

找到 [MySQL Monitor] 部分，修改 servers 为 server1,server2,server3，修改 user 和 passwd 为之前创建的监控用户的信息（scalemon,111111）。

找到 [Read-Write Service] 部分，修改 servers 为 server1,server2,server3，修改 user 和 passwd 为之前创建的路由用户的信息（maxscale,111111）。

由于我们使用了 [Read-Write Service]，需要删除另一个服务 [Read-Only Service]，删除其整块儿内容即可。

配置完成，保存并退出编辑器。

（4）启动 MaxScale

执行启动命令

maxscale --config=/etc/maxscale.cnf

查看 MaxScale 的响应端口是否已经就绪

netstat -ntelp

4006 是连接 MaxScale 时使用的端口
6603 是 MaxScale 管理器的端口

maxadmin --user=admin --password=mariadb

MaxScale> list servers

可以看到，MaxScale 已经连接到了 master 和 slave。

（5）测试

先在 master 上创建一个测试用户

mysql> grant ALL PRIVILEGES on *.* to rtest@"%" Identified by "111111";

使用 Mysql 客户端到连接 MaxScale

mysql -h MaxScale所在的IP -P 4006 -u rtest -p111111

执行查看数据库服务器名的操作来知道当前实际所在的数据库：

开启事务后，就自动路由到了 master，普通的查询操作，是在 slave上

MaxScale 的配置完成了。

4、 MaxScale 在 slave 有故障后的处理

前面已经介绍了 MaxScale可以实现MySQL的读写分离和读负载均衡，那么当 slave 出现故障后，MaxScale 会如何处理呢？

例如有 3 台数据库服务器，一主二从的结构，数据库名称分别为 master, slave1, slave2。

现在我们实验以下两种情况：

（1）当一台从服务器（ slave1 或者 slave2 ）出现故障后，查看 MaxScale 如何应对，及故障服务器重新上线后的情况

（2）当两台从服务器（ slave1 和 slave2 ）都出现故障后，查看 MaxScale 如何应对，及故障服务器重新上线后的情况

准备

为了更深入的查看 MaxScale 的状态，需要把 MaxScale 的日志打开：

修改配置文件

vi /etc/maxscale.cnf

找到 [maxscale] 部分，这里用来进行全局设置，在其中添加日志。

配置

log_info=1logdir=/tmp/

通过开启 log_info 级别，可以看到 MaxScale 的路由日志。

修改配置后，重启 MaxScale 。

实验过程

1、 单个 slave 故障的情况

初始状态是一切正常。

停掉 slave2 的复制，登录 slave2 的 mysql 执行。

mysql> stop slave;

查看 MaxScale 服务器状态

slave2 已经失效了。

查看日志信息

cat /tmp/maxscale1.log

尾部显示：

2016-08-15 12:26:02 notice : Server changed state: slave2[172.17.0.4:3306]: lost_slave

提示 slave2 已经丢失。

查看客户端查询结果：

查询操作全都转到了 slave1。

可以看到，在有 slave 故障后，MaxScale 会自动进行排除，不再向其转发请求。

下面看下 slave2 再次 上线后的情况。

mysql> start slave;

查看 MaxScale 服务器状态

slave2 已经失效了。

查看日志信息

cat /tmp/maxscale1.log

尾部显示：

2016-08-15 12:26:02 notice : Server changed state: slave2[172.17.0.4:3306]: lost_slave

提示 slave2 已经丢失。

查看客户端查询结果：

查询操作全都转到了 slave1。

可以看到，在有 slave 故障后，MaxScale 会自动进行排除，不再向其转发请求。

下面看下 slave2 再次 上线后的情况。

mysql> start slave;

查看 MaxScale 服务器状态

恢复了正常状态，重新识别到了 slave2。

查看日志信息，显示：

2016-08-15 12:32:36 notice : Server changed state: slave2[172.17.0.4:3306]: new_slave

查看客户端查询结果：

slave2 又可以正常接受查询请求。

通过实验可以看到，在部分 slave 发生故障时，MaxScale 可以自动识别出来，并移除路由列表，当故障恢复重新上线后，MaxScale 也能自动将其加入路由，过程透明。

2、 全部 slave 故障的情况

分别登陆 slave1 和 slave2 的MySQL，执行停止复制的命令

mysql> stop slave;

查看 MaxScale 服务器状态

发现各个服务器的角色都识别不出来了。

查看日志：

从日志中看到，MaxScale 发现2个slave 和 master 都丢了，然后报错：没有 master 了。

客户端连接 MaxScale 时也失败了。

说明从服务器全部失效后，会导致 master 也无法识别，使整个数据库服务都失效了。

对于 slave 全部失效的情况，能否让 master 还可用？这样至少可以正常提供数据库服务。

这需要修改 MaxScale 的配置，告诉 MaxScale 我们需要一个稳定的 master。

处理过程

先恢复两个 slave，让集群回到正常状态，登陆两个 slave 的MySQL。

mysql> start slave;

修改 MaxScale 配置文件，添加新的配置。

vi /etc/maxscale.cnf

找到 [MySQL Monitor] 部分，添加：

detect_stale_master=true

保存退出，然后重启 MaxScale。

验证

停掉两台 slave ，查看 MaxScale 服务器状态。

可以看到，虽然 slave 都无法识别了，但 master 还在，并提示处于稳定状态

客户端执行请求：

客户端可以连接 MaxScale，而且请求都转到了 master 上，说明 slave 全部失效时，由 master 支撑了全部请求。

当恢复两个 slave 后，整体状态自动恢复正常，从客户端执行请求时，又可以转到 slave 上。

小结

通过测试发现，在部分 slave 故障情况下，对于客户端是完全透明的，当全部 slave 故障时，经过简单的配置，MaxScale 也可以很好地处理。

来源：性能与架构订阅号（ID：yogoup）

作者：杜亦舒

饿了么分布式服务治理及优化经验

Thu, 18 Aug 2016 11:01:35 CST

导读：本文是兰建刚分享饿了么服务治理经验。

兰建刚，饿了么框架部门技术总监，前爱立信首席软件工程师，10 年以上高可用性，高并发系统架构设计经验。现饿了么框架工具部负责人，负责饿了么中间件的设计及实施，通过中间件以及研发工具的辅助提升研发人员的工作效率，提升网站的稳定性及性能。

今天我想站在一个大的角度上，看一下饿了么最近一年多的时间，经历的技术上一些痛苦的问题与改进的过程。

为什么讲比较痛苦的事情？昨天和一位专家聊天受益很大，他说人在什么时候能够自我驱动？就是痛苦的时候。 只有感到痛苦，才会有改变。当然改变有两种结果，一种是彻底放弃沉沦，另外就是一想办法自动化、智能化，把自己变成一个高手。

MVP 原则

我现在也很痛苦，但是还没有放弃。先讲一下 MVP 原则，MVP（Minimum Viable Product）现在比较火， 一个产品是做大而全，还是可用就行？我从去年 3 月份加入饿了么，开始组建框架和工具的团队。中间件里面很多东西都可以去做，但是我真的需要把所有的东西都做全吗还是 MVP 原则就好？这是我们思考的一个问题。

MVP 的意思就是做一个最小可用的就可以，大家以前很流行说，“世界那么大，我想去看看”，其实框架很多东西看看就好，做全做好是需要长时间积累的，我们缺的恰恰是时间。我们要做的就是立足现状，解决痛点问题。现在饿了么的现状说白了比百废待兴好一点。 当有太多事情可以去做的情况下，更需要抓住重点，不死人的尽量不要去踏。

服务治理的现状

服务治理是一个很大的话题，它涵盖了很多内容，比如前面晓波老师介绍的 Redis 治理、姚捷老师讲的链路监控系统，都可以涵盖在里面。

编程语言

先介绍语言，刚才会场一些人说他们是异构的语言，但可能还是没有饿了么这么复杂。饿了么语言主要有两种， Python 及 Java，原来整个公司语言都是以 Python 为主，可以说是上海最大的 Python 大厂。为什么不坚持用 Python？不是说 Python 语言不好，而是招不到人。在业务急速发展的时候怎么办？换 Java 语言就成了自然的选择。

在我进公司的时候，其实不仅仅是这两种语言，还有 PHP，C 语言等。基于这些现状，框架的选择点就比较少。因此做了一些妥协，SOA 的框架有两套，主要是为 Python 和 Java 做的，Python 的叫 Vespense，Java 版本的叫 Pylon，Vespense 和 Pylon 都是星际争霸里面的两种最基本的东西，没有这两种东西游戏根本打不下去。

SOA 框架

SOA 框架里面需要包含什么？ 首先必须包含 RPC，我们的 RPC 有两种：Thrift 和 JSON。Python 使用 Thrift，Java 使用 JSON。为什么 Java 框架重新选择一套 RPC 协议？主要是觉得 Thrift 对 Java 不太友好。举个例子，用 Thrift 生成的 Java 代码在接口比较多的时候，它的一个文件就超过 20M ，连 IDE 都拒绝分析这个文件。另外 JSON 是纯文本的，因为当初也没有日志系统，也没有链路跟踪系统，排查问题的时候，一种好的办法就是抓包，如果是一个二进制的协议的话那就痛苦。所以最终 Java 选择了 JSON。当然 RPC 都是对业务透明的，SOA 框架会屏蔽 RPC 细节，业务就像使用本地调用一样使用远程服务。

路由我们是基于集群做的，没有进一步细化到机器级别，因为觉得这个就足够了。此外也做了客户端的 SLB，还有熔断、降级、限流，这是保护服务的几大法宝，充分证明了这些东西拯救了我们很多次。经常看到监控群里面说，我们把什么什么服务限流了吧，把它降级了吧，那是因为这个服务可能写的不太好，把它降掉了，保住我们的主要业务。还有一些埋点，全链路跟踪等等，全部都内嵌在框架里面。这样的好处就是， 增加特性只要升级一个框架就可以了。

服务发现与配置中心

我们的服务发现和配置中心叫 Huskar，这是 DOTA 里面的一个英雄人物的名字，它是基于 ZooKeeper。

负载均衡

负载均衡有好几种， 首先有嵌在 SDK 里的软负载，拿到一个服务全部的列表，做一个轮循就可以了。这种策略有一些不足，比如一个 IDC 里面机器型号性能可能会稍微不一样，如果单纯用轮循会产生负载不均的问题。但这个问题当前还不是最紧迫的，我们可以绕过去，只要保证同一个集群里机器型号都是相同的就好。

此外也用中间层的方式，以前我们的 haproxy 用起来比较麻烦，配置复杂，而且它不能进行热加载，一个配置上去了之后需要重启一遍，因此工程师就用 Go 语言写了一个 GoProxy，基于四层，它会从服务中心把你需要的列表全部抓下来，做四层的负载均衡。他可以代理一些没有 SOA 框架支持的语言写的服务，也可以代理其他的基础组件，比如说像 Redis，数据库，它都会代理。

CI / CD 灰度发布

我们有 CI、CD 灰度发布的系统，叫 eless，虽然我们做了 CD 但是百废待兴，目前只有一些基本的单元测试，因为这个太耗工夫了。灰度发布也是基于发布系统做的，我们会在发布系统里面定义集群，每个集群里面的机器又分成不同的组，发布的时候按这些组来发布的，你可以先发一个组，观察没有问题后，然后再发其他的组。

监控与报警

我们有自己的监控和报警系统。 监控现在做的比较简单，是 statsd + graphite + grafana 的组合。现在最大的问题是监控系统不支持 tags，所有的指标汇聚到一起，一个服务的指标是汇聚在一起的，一个机器或者集群慢了，它会把这些指标分摊到其他机器或者集群上去的，所以查的时候比较困难，所以我们现在准备切成我们自己的系统。

报警系统也是自己写的。 报警系统的需要是快、全、准。我们现在做的是全，逼着大家去把报警系统用起来，只看监控系统是看不过来。如果线上发生了一个故障，比如交换机发生故障，影响到某个业务，但是业务报警没有报出来，那业务要承担连带责任，因为你没有报警出来。

报警最常见的基于阈值，阈值这件事情比较痛苦，我们有很多指标，但这个阈值怎么去配，需要很有经验的人才能配好，阈值配小了，你会经常收到报警，配太大有可能出问题收不到报警，这个非常痛苦。所以一个同事提出 基于趋势来配置来判断，我们在一段时间发现趋势在偏离了，就做报警。

我们也在做 trace，前两天终于把拓扑图给画出来，把一个业务所有的调用展示成一个调用树，这样就可以很好的分析业务。我们现在是一个近千人公司，业务系统极度复杂，很少有工程师能清晰说出一个业务到底调用了哪些服务，通过这种 trace 方式来做辅助分析就很有用了。

光展示，我们觉得它的价值还没有利用到极致，可以把所有的调用关系和报警结合在一起。大家分析问题的时候，会发现如果某个点上发生的错误一直往上报，从而导致整条链路失败，那这个点就是 root cause，把它修复就可以问题解决了。我们做 trace 的思路是一样的， 在调用链上进行着色，辅助找到问题的 root cause，也就是最初发生问题的那个点。

服务治理的经验

我们最重要的经验是做好保护与自我保护。

“不能被烂用的框架不是好框架”，这个是我们 CTO 经常说的一句话。原因是什么？比如我们那个监控的 SDK 曾经被业务错误的使用，每发一次报警就启一个新线程，最后整个进程因为开了太多的线程挂掉了。峰哥（CTO）说你无法预测每个开发者会怎么使用你的框架，即使框架被滥用了，最坏的情况，也需要保证能够活的下去。

所以后面写的东西都严格要求自我状态的检查，比如秒杀的时候，所有的监控系统，链路跟踪系统都是可以降级的，不能因为这些东西导致整个系统崩溃。

框架由于在底层，出了问题最容易被怀疑。比如一个 SDK，使用方说为什么占用了整个集群上 8% 的 CPU？跑过去一看，整个机器的 CPU 才 12%。某种程度做框架其实有无助的时候，容易被质疑及谴责，所以做好自我状态检查是很必要的。

定期线上扫描

为了避免滥用的问题，我们会定期线上扫描。比如一些日志本来就是可以降级可以丢的，但如果开发用了写文件的同步方式，那性能就会变慢，通过扫描发现这些问题，改成异步日志服务性能就会更好。

限流、熔断、降级

这个强调多少遍都不过分，因为确实很重要。服务不行的时候一定要熔断。限流是一个保护自己最大的利器，原来我们前端是用 PHP 做的，没有自我保护机制，不管有多少连接都会接收，如果后端处理不过来，前端流量又很大的时候肯定就挂了。所以我们做任何框架都会有限流措施。

有个小插曲，我们上 DAL （数据库中间件）第一版的时候，有次一个业务怎么指标突然降了 50%，然后大家去查，原来 DAL 做了限流，你不能做限流，你把它给我打开，听你们的我打开了，打开了然后数据库的 QPS 瞬间飙到两万，业务部门就慌了，赶紧邀请我们再给他限制住。这是我觉得 DAL 做的最好的一个功能。

连接复用

还有连接复用，有些工程师并不能特别理解，如果不用连接池，来一个请求就发一个连接怎么样？这样就会导致后端资源连接过多。对一些基础服务来说，比如 Redis，数据库，连接是个昂贵的消耗。所以我们一些中间件的服务都实现了连接复用的功能。

代码发布

上线发布是很危险的一件事情，绝大部分的事故都是由发布引起的，所以发布需要跟很多系统结合起来，所以我们做了整套流程。在每次发布的时候，一个发布事件开始，到我们这个监控系统以及调用链上，调用链就开始分析了， 发布后把它的所有指标比一比，到底哪些指标发生了改变，这些指标如果有异常，就发报警，所有发布都会打到监控的主屏上面去，如果出了什么问题，这些事情优先回滚，如果可以回滚，我们肯定第一时间就把问题解决掉了。

服务治理的痛点

配置复杂

超时配置：超时配多少是合适的？100ms？300ms？极端情况有些业务配到 3 秒的。阈值怎么配和超时怎么配其实是同一个概念，并不是所有的程序员都知道超时设成多少合适。那怎么办？峰哥（CTO）想了一个办法，你的监控系统，你的调用链分析系统，你的日志系统，基础监控系统每天产生多少数据？这些数据到底有没有用？是否可以从这些数据里面挖掘出一些东西，比如这种超时的配置，是可以基于它历史的超时配置、所有请求的响应时间去做的。

这件事情正在进行中，但落地有点麻烦，比如说我们请求大概每天有三千万的调用量，你只有很小的一个比例它会超时，但是绝对量是很大的，你设置一个超时值，它可能有三万个请求都失败了。现在一直在优化这个东西，希望下次大家来我们这里的时候，能给大家详细介绍一下这个超时到底怎么做。

线程池配置：刚才说最重要的是限流，你不可能无限制的接受请求，不可能一百个并发你就接收一百个并发，并发到底怎么配？又是很复杂的事情。我经常看我们线程池的配置，这个东西要经过严格的性能测试，做很多调整才能调出来。在做性能测试的时候，其实有条曲线的，有个最高点的，我们在想在实时的过程中计算出这个最高点，但发现这个东西其实挺难的。

我们便用了另外一种方法， 每个线程池用一个排列队列，当我发现它在涨的时候我就适当把那个线程池扩大一点，同时我们监测其他指标。如果发现在我扩大并发量的时候这些指标产生了报警，那我就把这个线程调整的操作直接拒绝掉，就保持原来那个大小。如果这些指标证明是没有问题的，那我就把它再扩大一点。

Cache，DB，Queue 的手工配置问题。还有一个是服务治理，Redis、数据库等配置还都是手工的，我们也不知道我们线上有 Redis，怎么办？我们正在做基础服务的服务化，业务其实不需要关心到底连到哪个 Redis，你上线的时候你告诉我你需要多大的容量，填个工单过来，运维帮你配好了，然后通过一些自动化的方式你把这些拿到初始化 SDK 就可以了。

故障定位

还有一个比较痛的问题就是排查问题很难。首先故障定位困难，每次我们出了事情之后，大家各自查各自的，比较低效。问题排查其实是有方法可以做，需要把它自动化，我们现在还缺这个东西，调用链分析是需要考虑去做。

性能退化

我们现在的业务增长量非常恐怖，去年我们是以 5 倍的速度增长了，但其实这个 5 - 10 倍要看你的基数，当基数很大，扩一倍量也是非常多，评估线上到底要布多少台机器是一件很复杂的事情。

我们成立一支性能测试团队，做全链路的压测。基于全链路压测的结果来评估整个系统的容量。这个全链路只能在线上做，也不能在白天压，只能在晚上低峰期的时候做。所以性能测试也是一个比较挑战的工作，不仅仅是智力上，也是身体上的一种考验。

全链路压测试一些服务有时候出现性能下降，比如 QPS 从 500 下降到了 400，但大家并不知道最直接的原因。上次毕洪宇老师也帮我们出了主意，比如把全链路指标拉出来做一下对比，看看哪些指标有变化，可能就是罪魁祸首。

容量评估的方法

容量评估方面容易出现温水煮青蛙的事情，今天流量增长一点没问题，明天再增长一点也没有问题，连续几天然后服务就挂了。这个时候怎么办？只能用最苦逼的方法，找个性能测试团队进行压测。有没有更智能化的方法？我们也正在探寻这条道路。

资源利用率低

资源利用率低的问题。很多团队一碰到性能下降，就希望扩容，这会导致很多时候机器利用率只有 10%（更新一下数据，其实很多服务器的利用率不足1%）。我们正在积极准备上容器化方案来解决这个问题。

服务依赖不清晰

大的系统中，服务依赖的调用链相当复杂，一个业务下去到底调用了哪些服务比较难说清。我们已经在做一个泳道规划。泳道这件事情有多种说法，有的人喜欢所有的服务都做一个大池子，只要保证它的足够容量就可以了，但是我更倾向小集群的思路，因为隔离起来就会更安全。

我们现在还没有做到按用户来区分泳道，目前只是按流量来切，50% 随机，部署的东西都一样。我们想通过泳道把这些流量隔离，VIP 客户可以把他放最重要的泳道里面，一些不那么重要的城市，可以放到另一个集群，如果不得已降级，只能牺牲这些次重要的用户。

服务治理的方向

有痛点就要努力，要么放弃，要么努力，这是我们努力的方向，前面讲了一下智能流控系统，超时推荐我们也做，大数据和智能化才是将来。有些监控数据只是落在磁盘上不用那就是浪费，是不是能把它利用起来？

然后我们也在做 Cache、数据库、Queue 等服务化。

Trace 系统我们也在做，拓扑图画出来，帮助大家了解是怎么回事，我们可以做链路染色，帮你了解问题的根源在哪里，我们也可以做依赖度的分析。我们说依赖分两种，强依赖和弱依赖。弱依赖要处理它，有一个异常出来的时候要把它干掉，不能把这个异常跑到最上面去，那整个服务就都挂掉了，但是大家并不知道到底它是弱依赖还是强依赖，这需要分析，我们去统计一下，它是一个强依赖还是弱依赖。然后弱依赖就可以做一些改进，比如做一些异步调用，节省整个服务的调用时间，优化用户体验。

容量预警我们通过做一些大数据的分析，所有的指标跟订单量这些关联，做一个相似度的分析，当这些指标偏离的时候，我们是不是可以认为它的容量有问题，当然这是努力的方向。

容器方面我们也在做，系统叫 APPOS，有的服务 CPU 只用了10%，但是我们规定了一台服务器只能装一个服务怎么办，那就上容器吧。

Q&A

提问：想问一下报警阈值设定，上面提到的方法是根据趋势来设计报警，这个趋势其实您能做到多少准确？能控制在什么情况下？

兰建刚：准确度的确是个问题，我们用了一个算法叫 3-sigma，准确度还不是特别确定，因为这个东西真的是服务治理里面最大的难题，报警分级怎么分？这是很大的学问，我们现在整个报警系统里面报警通道每天上千个报警，很多都不看的，因为觉得这个报警没什么意义。这是一个实际当中要去调整的问题。

提问：报警存在误报的情况？

兰建刚：对，你要知道我们的业务有两个明显的尖峰，十二点和下午四五点的时候都是订餐的高峰，之后则所有的指标都会有下降趋势的时候，如果你曲线偏离的很厉害就会引发报警。

多指标聚合是我们正在做的，发生一个指标报警的时候可能是一个小问题，但是这个问题会触发一个 CEP 的流程，比如“是不是 CPU 飙高的同时响应时间会抖动？”，我们可以定义这样整个一套规则，去做报警来提高准确度。

提问：刚才您提到用 Go 写的一个东西，为什么选择使用 Go 因为 Go 是自己的垃圾回收机制？而且我想了解一下您认为 Go 它是比较适合什么样的系统？

兰建刚：当然是底层的基础服务了，我们不建议用 Go 写业务。为什么我们选 Go 做工具，是因为我前面提到，公司原来一些工具是搭在 Python 上，有一帮 Python 工程师，让他去写 Java 他是绝对不干的，但是让他去写 Go 语言是没有问题的，Python 其实不适合写底层框架，因为它是个动态语言，工程化方面也会差一点。

提问：刚刚看到您提到超时配置推荐，这块是和你们的应用场景有关系，还是说和你们遇到的故障？

兰建刚：就是因为遇到故障了，因为很多超时配得很乱，有的同学直接配 3 秒超时（这是配置模版里的一个例子，很多同学就拿去直接用了），那还不如不配，有些情况很多服务就是 10ms 就正常返回了。只要保证这件事情对绝大部分的服务来说，是有利可图的，那我们就去做这件事情。

讲师演讲PPT下载地址：http://pan.baidu.com/s/1nvnOEBf

文章出处：高可用架构

APP的推送是咋回事

Sun, 13 Dec 2015 14:28:26 CST

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

相信大家对推送这项技术并不陌生。如果没听说过，那么作为一个充满好奇心的孩子，你一定想过这个问题：睡觉前我明明关闭了淘宝、网易新闻等app，为什么第二天他们又自动出现在我手机的通知栏上呢？这其实就是推送系统干的好事：在你睡觉的时候，服务器悄悄的向你的手机推送了一个消息，然后唤醒了你已经关闭的app。事实上，无论你愿意与否，现在大多数‘有节操’的app，都已经内置了推送系统，并时刻准备着登上你的通知栏的‘头条’。

传统的app架构里，通常是app主动向服务器请求数据，服务器被动的提供数据。以新闻客户端app为例：app被用户打开的时候，会通过网络(无论3g、4g还是wifi)连接到服务器上，向服务器请求最新的新闻。服务器收到请求，从自己的数据库里查询最新的新闻，返回给app。app收到服务器返回的数据，经过一系列的解析处理操作，最终把最新的新闻呈现给用户。一次通信就完成了。然而如果此时服务器上又有了新的新闻，无论多么重要，在用户没有主动刷新的情况下，是没有办法让用户看到的。推送就是为了解决这样的困境的，它给了服务器一个展示自我的机会，主动连接上所有的app，告诉他们我有新的新闻了，你们再来请求一次吧，于是收到推送的app（即时此时已经被用户关闭了）又去服务器请求最新的新闻，这样用户就能看到最新的新闻了。

从技术上来讲，实现一个推送系统需要服务器端和终端的配合。一种方法是轮询，也就是不停的向服务器发起请求。这其实很好理解，作为app，我既然不知道什么时候会发生新的新闻，那我一遍一遍的问好了，而且我知道这样一定会成功的。显而易见，这种方法app端费时费力不说，电量流量也扛不住啊，服务器要处理如此量大的请求，必然也是非常头疼的。另一种方法是服务器和app建立一个长时间连接的通道，通过这个通道，不仅app可以向服务器请求数据，服务器也可以向app发送数据，看起来非常完美，但是如果app被用户关闭的话，通道就断掉了。好在android系统给app提供了一个这样的环境，app可以启动一个后台服务来维持这个通道，即使app被关掉了，服务依然可以运行，通道依然还在工作（ios后面会讲）。回到前面的例子，你在睡觉前关掉了淘宝，但是并没有关闭淘宝的后台服务，淘宝依然可以接收服务器推送来的指令，把自己的唤醒。

那么如何维持这样的一条长时间连接的通道呢？就好比两个人打电话，一开始聊的热情有来有往，后来慢慢沉默下来了，几分钟之后，电话的另一头没有任何动静，如何知道那边的人还在呢？很简单，只需要另一头的人每隔几分钟说一个字就行。同样的道理，app会每隔一段时间向服务器报告自己还活着，就像心跳一样，服务器收到后，就知道这个通道是可以继续使用的了。然而天下没有免费的午餐，发送心跳是有代价的，一般手机锁屏之后，为了省电CPU是出于休眠状态的，然而发送心跳就会唤醒CPU，必然会增加电量的消耗。这还只是一个长连接通道的情况，如果手机里装了2、30个带有推送的app呢？先别急着抱怨，聪明的android工程师和ios工程师早就想到了这一点，他们分别设计了GCM和apns来解决多个app有多个长连接通道的问题。以apns为例，ios开通了一条系统级别的长连接通道，通道的一端是手机的所有app，另一端是苹果的服务器。app的服务器如果有新的消息需要推送的话，先把消息发送到苹果的服务器上，再利用苹果的服务器通过长连接通道发送到用户手机，然后通知具体的app。这样就做到了即使手机安装了100个app，也只需要向一条通道里发送心跳。

回到Android，系统提供的GCM只能在Android2.2以上才能使用，3.0以下必须要安装Googleplay并登陆了Google账号才能支持。而国内发行的手机大多是阉割掉了google 服务的。因此，对于Android系统来说，各家app只能各显神通，开发自己的专用长连接通道了。然而这时候他们遇到了app的天敌：管家和卫士们。前文说了，app想要及时收到服务器推送的消息，关键在于自己与服务器的长连接通道不被关闭，也就是自己的后台服务可以一直在后台运行，而管家和卫士们的一键清理功能就是专治这种“毒瘤”的。道高一尺魔高一丈，app在与管家和斗士们的长期斗争中，总结了一系列躲避被清理掉的方法，什么定时自启能力、什么相互唤醒、什么前台进程等等，当然这就是另一个话题了,我们后面会讲到。

总结起来，app和后台的连接方式有两种。一种叫pull，也叫轮询，就是定期的不断向后台请求，缺点是耗电，费流量，不环保。对于一名有追求的程序员，他应该会比较恶心这种方式的，你千万不要对他说，我不管你怎么实现，我就要这种效果这种傻逼话了，凡事应该找到最优路径。另一种叫push，app和后台一直维持了一条通信通道，两端不定期的就会偷摸的约会，告诉对方“I‘m Here”，也能顺带把信息互相携带了。缺点是要维持一条长连接通道，这条通道容易被其他程序杀死，要多想复活办法。

原文链接，点击查看。

说说下载劫持那些事儿

Sun, 13 Dec 2015 14:30:08 CST

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

今年的双十一，想必广大千手观音们又狠狠的剁了几只手。然而，剁手换来的宝贝在漫漫快递路上也是命途多舛，轻者磕磕碰碰包装损毁，重者与快递货车一起被付之一炬。这些“不可抗力”造成的问题屡见不鲜，碰到了也只能自认倒霉。不过，有的网友看着苹果6代的订单，却啃着寄过来的6袋苹果，个中滋味大家就自行脑补吧…。其实，在安卓应用分发领域，这种“苹果6代”变“6袋苹果”的情况也屡见不鲜：

为什么会出现这种情况呢？其实一次网络下载的过程，就像一次“网购”，当我们点击下载按钮时，就跟下载服务器下了一份“订单”，“订购”了一个文件（当然大部分是免费的），服务器确认“订单”后，就会将文件在网络中“快递”（传输）到用户的终端（手机、PC等）。下载劫持一般出现在“下订单”的过程中。

举个栗子，假设我们通过微信官网的链接http://dldir1.qq.com/weixin/android/weixin637android660.apk下载微信安卓版本的客户端，整个流程大概是这个样子：

当点击了下载按钮后，客户端会通过url中的“域名”“dldir1.qq.com”来向DNS服务器获取确认“订单（下载）服务器”的IP地址，IP地址在互联网中相当于日常生活中“电话号码”，有了它，就可以连接到这台“订单（下载）服务器”，而DNS服务器就像一个存贮着大量“姓名”（域名）和“电话号码”（IP地址）的黄页。

当客户端获得了“订单（下载）服务器”的“电话号码”（ip地址）后，就会连接“订单（下载）服务器”，并告知“订单（下载）服务器”客户端需要获取服务器上的“微信安卓版”apk文件，一般情况下，服务器在这个阶段确认了“订单”后，就会向客户端“快递”（传输）对应的apk文件，当客户端将文件下载完毕后，这次“网购”也就完成了。

下面，我们引入运营商（电信、联通等）网关的概念。运营商网关可以类比成日常生活中的“总机”，接入运营商的互联网设备想要能够“上网”，都需要经过“总机”（运营商网关）的转接。也就是说，在上图中的第二步，我们并不能直接通过“订单（下载）服务器”的“电话号码”（IP地址）联系到“订单（下载）服务器”，而是需要先连接到“总机”（网关），并且告诉它，我们要向某某某服务器下“订单”，经过“总机”的转接，我们才能真正连接到“订单（下载）服务器”。整个过程如下图：

可以发现，DNS服务器和网关的决策，确定了客户端“订单”（下载请求）的走向。而“下载劫持”也就发生在这两个关键节点上。

假设客户端获取下载服务器“电话号码”的DNS服务器被篡改，那么客户端可能会通过“dldir1.qq.com”查询到一个“骗子服务器”的“电话号码”（IP地址），当我们联系到这个“骗子服务器”时，我们的“订单”（下载请求）可能会换来一些奇奇怪怪的“商品”。

当我们遇到这种情况时，可以手动修改DNS服务器IP（具体方法请问度娘）来解决。然而当运营商的“总机”（网关）“出了问题”（这些“问题”一般是运营商主动造成的）时，就没那么容易解决了。

假设当客户端拿着“订单（下载）服务器”的电话号码要求“总机”（网关）转接到我们指定的“订单（下载）服务器”时，“总机”（网关）对客户端说“哎呀，不要去A家下载微信了，你去我给你介绍的B家下载“XX助手”吧，比微信好用”（这个过程在技术上是被一个叫做302跳转的机制完成的，如果你不知道什么是302，出门左转，查询我们星期一的文章）。客户端是个实在人，就这样被“引诱”到B家的服务器上下载了。

“总机”（网关）和服务器B就这样沆瀣一气，来骗客户端的下载量。

刚刚给大家从技术层面简单介绍了下“下载劫持”的“饭醉手段”，至于为什么有人要做“下载劫持”，想必产品同学们应该比我更能知晓其中的奥妙，我就不班门弄斧了。就写到这里吧，我去洗水果了，双十一寄来的六袋苹果，再不吃就烂了….

（文中“XX助手”和服务器IP地址均属臆造，如有雷同，我也不知道是咋回事儿）

原文链接：点击查看。

移动web问题小结

Sun, 14 Jun 2015 19:29:21 CST

Meta标签：

<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" />

这个想必大家都知道，当页面在手机上显示时，增加这个meta可以让页面强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览。

<meta content="telephone=no" name="format-detection" />
<meta content="email=no" name="format-detection" />

这两个属性分别对ios上自动识别电话和android上自动识别邮箱做了限制。

获取滚动条的值：

window.scrollY  window.scrollX

桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？就是上面两个属性，但是事实证明android也支持这属性，所以索性都用woindow.scroll.

禁止选择文本：

-webkit-user-select:none

禁止用户选择文本，ios和android都支持

屏蔽阴影：

-webkit-appearance:none

亲测，可以同时屏蔽输入框怪异的内阴影，解决iOS下无法修改按钮样式，测试还发现一个小问题就是，加了上面的属性后，iOS下默认还是带有圆角的，不过可以使用 border-radius属性修改。

css之border-box：

element{
        width: 100%;
        padding-left: 10px;
        box-sizing:border-box;
        -webkit-box-sizing:border-box;
        border: 1px solid blue;
}

那我想要一个元素100%显示，又必须有一个固定的padding-left／padding-right，还有1px的边框，怎么办？这样编写代码必然导致出现横向滚动条，肿么办？要相信问题就是用来解决的。这时候伟大的css3为我们提供了box-sizing属性，对于这个属性的具体解释不做赘述（想深入了解的同学可以到w3school查看，要知道自己动手会更容易记忆）。让我们看看如何解决上面的问题：

css3多文本换行：

p {
    overflow : hidden;
    text-overflow: ellipsis;
    display: -webkit-box;
    -webkit-line-clamp: 2;
    -webkit-box-orient: vertical;
}

Webkit支持一个名为-webkit-line-clamp的属性，参见链接，也就是说这个属性并不是标准的一部分，可能是Webkit内部使用的，或者被弃用的属性。需要注意的是display需要设置成box，-webkit-line-clamp表示需要显示几行。

Retina屏幕高清图片：

selector {
  background-image: url(no-image-set.png);
  background: image-set(url(foo-lowres.png) 1x,url(foo-highres.png) 2x) center;
}

image-set的语法，类似于不同的文本，图像也会显示成不同的：

不支持image-set：在不支持image-set的浏览器下，他会支持background-image图像，也就是说不支持image-set的浏览器下，他们解析background-image中的背景图像；
支持image-set：如果你的浏览器支持image-sete，而且是普通显屏下，此时浏览器会选择image-set中的@1x背景图像；
Retina屏幕下的image-set：如果你的浏览器支持image-set，而且是在Retina屏幕下，此时浏览器会选择image-set中的@2x背景图像。

html5重力感应事件：

if (window.DeviceMotionEvent) { 
                 window.addEventListener('devicemotion',deviceMotionHandler, false);  
        } 
        var speed = 30;//speed
        var x = y = z = lastX = lastY = lastZ = 0;
        function deviceMotionHandler(eventData) {  
          var acceleration =event.accelerationIncludingGravity;
                x = acceleration.x;
                y = acceleration.y;
                z = acceleration.z;
                if(Math.abs(x-lastX) > speed || Math.abs(y-lastY) > speed || Math.abs(z-lastZ) > speed) {
                    //简单的摇一摇触发代码
                    alert(1);
                }
                lastX = x;
                lastY = y;
                lastZ = z;
        }

关于deviceMotionEvent是HTML5新增的事件，用来检测手机重力感应效果具体可参考 http://w3c.github.io/deviceorientation/spec-source-orientation.html

移动端touch事件：

touchstart //当手指接触屏幕时触发
touchmove //当已经接触屏幕的手指开始移动后触发
touchend //当手指离开屏幕时触发
touchcancel//当某种touch事件非正常结束时触发

这4个事件的触发顺序为：

touchstart -> touchmove -> touchend ->touchcancel

对于某些android系统touch的bug:

比如手指在屏幕由上向下拖动页面时，理论上是会触发一个 touchstart ，很多次 touchmove ，和最终的 touchend ，可是在android 4.0上，touchmove只被触发一次，触发时间和touchstart 差不多，而touchend直接没有被触发。这是一个非常严重的bug，在 google Issue已有不少人提出 ,这个很蛋疼的bug是在模拟下拉刷新是遇到的尤其当touchmove的dom节点数量变多时比出现，当时解决办法就是用settimeout来稀释touchmove。

单击延迟：

click 事件因为要等待双击确认，会有 300ms 的延迟，体验并不是很好。

开发者大多数会使用封装的 tap 事件来代替click 事件，所谓的 tap 事件由 touchstart 事件 + touchmove 判断 + touchend 事件封装组成。

Creating Fast Buttons for Mobile Web Applications

Eliminate 300ms delay on click events in mobile Safari

IOS里面fixed的文本框焦点居中

<!DOCTYPE html>
    <head>
    input {
       position:fixed;
       top:0;left:0;
    }
    </head>
    <body>
        <div class="header">
            <form action="">
                <label>Testfield: <input type="text" /></label>
            </form>
        </div>
    </body>
</html>

在ios里面，当一个文本框的样式为fixed时候，如果这个文本框获得焦点，它的位置就会乱掉，由于ios里面做了自适应居中，这个fixed的文本框会跑到页面中间。类似：

解决办法有两个：

可以在文本框获得焦点的时候将fixed改为absolute，失去焦点时在改回fixed，但是这样会让屏幕有上下滑动的体验不太好。

.fixfixed {
position:absolute;
}
$(document)
    .on('focus', 'input', function(e) {
        $this.addClass('fixfixed');
    })
    .on('blur', 'input', function(e) {
        $this.removeClass('fixfixed');
    });

还有一种就是用一个假的fixed的文本框放在页面顶部，一个absolute的文本框隐藏在页面顶部，当fixed的文本框获得焦点时候将其隐藏，然后显示absolute的文本框，当失去焦点时，在把absolute的文本框隐藏，fixed的文本框显示。

.fixfixed {
position:absolute;
}
$(document)
    .on('focus', 'input', function(e) {
        $absolute..show();
        $this.hide();
    })
    .on('blur', 'input', function(e) {
         $fixed..show();
        $this.hide();
    });

最后一种就是顶部的input不参与滚动，只让其下面滚动。

position:sticky

position:sticky是一个新的css3属性，它的表现类似position:relative和position:fixed的合体，在目标区域在屏幕中可见时，它的行为就像position:relative; 而当页面滚动超出目标区域时，它的表现就像position:fixed，它会固定在目标位置。

.sticky { 
position: -webkit-sticky; 
position:sticky; 
top: 15px; 
}

浏览器兼容性：

由于这是一个全新的属性，以至于到现在都没有一个规范，W3C也刚刚开始讨论它，而现在只有webkit nightly版本和chrome 开发版(Chrome 23.0.1247.0+ Canary)才开始支持它。

另外需要注意的是，如果同时定义了left和right值，那么left生效，right会无效，同样，同时定义了top和bottom，top赢～～

移动端点透事件

简单的说，由于在移动端我们经常会使用tap(touchstart)事件来替换掉click事件，那么就会有一种场景是：

<div id="mengceng"></div>

<a href="www.qq.com">www.qq.com</a>

div是绝对定位的蒙层z-index高于a，而a标签是页面中的一个链接，我们给div绑定tap事件：

$('#mengceng').on('tap',function(){
$('#mengceng').hide();
});

我们点击蒙层时 div正常消失，但是当我们在a标签上点击蒙层时，发现a链接被触发，这就是所谓的点透事件。

原因：

touchstart 早于 touchend 早于 click。亦即click的触发是有延迟的，这个时间大概在300ms左右，也就是说我们tap触发之后蒙层隐藏，此时click还没有触发，300ms之后由于蒙层隐藏，我们的click触发到了下面的a链接上。

解决办法：

1 尽量都使用touch事件来替换click事件。

2 阻止a链接的click的preventDefault

base64编码图片替换url图片

u在移动端，网络请求是很珍贵的资源，尤其在2g或者3g网络下，所以能不发请求的资源都尽量不要发，对于一些小图片icon之类的，可以将图片用base64编码，来减少网络请求。

手机拍照和上传图片

<input type=”file”>的accept 属性

<!-- 选择照片 -->
<input type=file accept="image/*">
<!-- 选择视频 -->
<input type=file accept="video/*">

动画效果时开启硬件加速

我们在制作动画效果时经常会想要改版元素的top或者left来让元素动起来，在pc端还好但是移动端就会有较大的卡顿感，这么我们需要使用css3的 transform: translate3d;来替换，

此效果可以让浏览器开启 gpu加速，渲染更流畅，但是笔着实验时在ios上体验良好，但在一些低端android机型可能会出现意想不到的效果。

快速回弹滚动

在iOS上如果你想让一个元素拥有像 Native 的滚动效果，你可以这样做：

.div {
        overflow: auto;
        -webkit-overflow-scrolling: touch;
    }

经笔着测试，此效果在不同的ios系统表现不一致，

对于局部滚动，ios8以上，不加此效果，滚动的超级慢，ios8一下，不加此效果，滚动还算比较流畅

对于body滚动，ios8以上，不加此效果同样拥有弹性滚动效果。

持续更新中。。

参考资料： http://www.nihaoshijie.com.cn/index.php/archives/455

产品经理5点工作经验总结

Mon, 16 Mar 2015 00:32:25 CST

根据自己在产品工作中碰到的问题做一个总结，期望这样的总结能成为自己更优秀的垫脚石。也许它们让一些人看来有些幼稚，但是每个人的成长都是螺旋上升的，没有人可以直接造第三层楼。

会议主持

产品经理每天有开不完的会是很正常的。那么如果是自己主持一次会议，第一，与会人员最好控制在10人以内，其实人一多，效率就会急剧下降，你一句我一句，1小时的会议拖成2个半小时也是很有可能的（经常发生），很多时候会后找负责人单独沟通，有时效率更高；第二，与会时间最好控制在45分钟以内，把要讨论的问题提前发邮件通知到各位，让大家心里都有数，开会的时候控制好各位的思维，不要太发散，有时候大家的自认为的目标可能不一定一致，会出现大家不在一个频率上的事，所以需要主持人把控好，及时提醒纠正。

思考换位

很多时候我们产品经理做出一个功能会觉得自己很牛，自己就是对的，把「用户体验」当作说词，那么，我们要冷静回想一下，这真的是站在用户的角度考虑问题了吗？自己很喜欢自己的设计，你能保证用户也喜欢吗？自己能把逻辑讲得头头是道，用户懂你的逻辑吗？你是商业目的为先，还是用户体验为先？你是希望用户快速做决策还是把大量信息堆在用户面前让用户自己选？

不同的答案就会产生不同的设计结果，需谨慎考虑。换位思考其实挺难的，你不能保证自己想切换思维的时候就能切换，具体怎么提高，我总结了两种方式，一是做用户访谈，不用很高科技，拿着原型问问身边的同事，他们想要什么，你会发现很多的想法跟自己完全不同；二是看心理学的书籍，看看别人都是怎么考虑问题的，跟自己的思路有什么不同。

沟通表达

沟通能力作为一名产品经理来说再怎么强调它的重要性都不为过。首先，沟通的过程中不要和别人发生不愉快，这是最基本的，也就是要会说话，包括说话的方式、角度、语调、声调，换句话说，要让别人愿意听下去，先不管讲的内容是什么。这些事情搞定后就要升级沟通能力了，也就是每个产品经理都会经历的需求评审、交互评审、设计评审、技术评审等环节，俗称PK。

这个过程会和形形色色的人沟通，每个人的性格都完全不一样，而且同一个人在不同时间段的状态也是差异很大的，比如在你和他讨论之前他可能刚刚跟另外一个产品经理「争吵」完，情绪还没缓过来，这个时候找他去沟通，就会超出自己的预估，也有可能刚接到电话得知老婆跟别人吵架了，思绪还在老婆那边。所以要对环境作出快速正确的判断，然后达成自己的目标。总的来说，遇到这种情况，通常应该尊重理解对方，学会换位思考，这是很重要的。其实每一次的PK都是类似谈判的过程，可以用一些有效的谈判方式来进行沟通。还要说一点，沟通前，得自己先把问题逻辑想清楚，自己这边先过关。

原型制作

我看到周围的一些同事用什么原型软件的都有，有人用 Axure，有人用 photoshop，有人用sketch，有些人甚至不用软件，一直靠文字和截屏来说明问题，这些都可以，哪怕直接口头表达，都没问题的，只要能达到目标就行。但是就我观察到情况来看，在需求评审时，如果没有原型，开发会抱怨，因为一旦牵扯到逻辑或交互的修改，很难表述清楚，在开发的脑海里形成不了具象的概念；如果有原型而且包含颜色丰富的视觉，交互会抱怨，因为这抢了交互设计师的工作，每个人都需要存在感。

所以我比较推荐的做法是画灰度原型，而且要尽量精准，什么叫精准，不同的元素要用不同的灰色对比度，文案要用实际真实的文案，而不是随便写几个汉字，这样大家在评审事就能专注于功能、交互、文案等信息了。另外对于原型软件的选择上，我的原则是越轻便越好，在最短的时间内完成目标就是最好的，因为自己负责的是移动端，一般就使用「墨刀」这个软件，用了一段时间非常不错，也推荐给大家。

文案细节

我听说有些公司在制作一款 APP 时会把APP中的文案部分单独拿出来给一个公关部门负责，产品经理只要负责功能就可以了，我觉得这种做法是很愚蠢的，我们是产品经理，不是功能经理。不能整体把握会让自己的视域变窄，要不得。

我们在设计APP的时候不能只关注功能逻辑，文案也很重要。文案在哪儿呢？一个就是我们打开APP很明显就能看到的各种标题、段落文字，一个就是各种输入框中灰色显示的提示文字，还有当我们触发不正确操作时弹出的 Toast 上的文字，这些都需要我们去关注，比如一个 APP 中，有些地方写「手机」，有些地方写「手机号」，有些地方写「手机号码」，是不是考虑需要统一下？有些地方写「请填写」，有些地方写「请输入」，是不是考虑需要统一下？有些地方用全角括号，有些地方用半角括号，是不是考虑需要统一下？功能改进能看出一家公司的创造力，文案细节能看出一家公司的专业度。

本文由 @沈晓马投稿发布，本文禁止在本人未允许的情况下，任何形式的全文转载和部分转载。若您喜欢本文，请分享本文的链接到您喜欢的平台。

互联网从业者必备微信公众号：woshipm，如果你已经关注了，证明你已经很牛逼了。

SEM经验谈之数据呈现小技巧

Mon, 23 Mar 2015 00:23:45 CST

本篇文章来自我的朋友王硕，他在SEM领域沉浸多年。他将通过一系列文章与大家分享自己在SEM工作中获得的经验。如果你对他的文章感兴趣，或希望了解更多SEM的知识，又或对文章内容有任何疑问，请在本篇文章后留言。

王硕 2009年入行，有5年以上SEM从业经验，第一批通过百度中级认证的从业者。曾在多家知名大型互联网公司任SEM负责人，包括链家地产，百合网，搜狐畅游等。目前在某互联网金融公司任线上广告投放总负责人。对各搜索引擎的关键字广告和网盟等展示类广告的投放和优化工作拥有丰富的经验。

关于SEM的文章，大都在讲，如何搭建账户，如何选择关键词，如何出价等等。但这些并不是SEM工作的全部。即使这些做的都没有问题，在日常SEM工作中，我们仍然会遇到各种各样让我们棘手的困难。根据我这些年的从业经验，恰恰是这些优化之外的问题，带给我们的压力更大。所以，我的SEM文章，会抓住一些能够解决某个日常工作的痛点来写，希望大家在工作中遇到类似问题时，能更加稳妥的进行处理。比如，今天我们就来谈谈，给客户（对于甲方同学来说，老板就是你的客户）呈现数据时的一个小技巧。

大部分SEM优化师，给客户呈现投放数据时，都是把SEM整个的投放数据直接拿出来，例如下面的样子：

客户看到后，一目了然，知道10月20日当天投放总体是一个什么情况。但这样的数据呈现方法，是有隐患的。

我们都知道，SEM的关键词，主要分为，品牌词，竞品词，通用词等。这些词类的划分，本质上是面对的人群不一样。例如品牌词，都是已经知道这个品牌的人，一般来说，品牌词的点击率转化率都会较高，成本较低。竞品词，则是已经知道竞争对手品牌的人，一般竞品词的点击率较差，CPC和成本较高。通用词，是对我们的产品有需求，但没有明确品牌导向的人群，通用词的投放效果，是最考验我们优化师水平的。

既然，SEM不同的关键词对应了不同的人群，那么在不同的人群受到市场消息的刺激后，就会做出不一样的反应。这些就会体现在SEM的数据变化上。最常见的就是，客户做了电视广告。

如果客户做了电视广告，之后看到数据是这样的：

这时，当然是皆大欢喜。但是，电视广告那么贵，客户可能做了几个星期之后，不做了。那么，之后客户见到的的数据，就会是这样的：

这个时候，优化师就比较被动了。我曾经尝试过多种办法向客户解释数据下降的原因，但大多会被客户反驳或质疑，不可避免的降低客户对我们的信任感。例如，我直说是广告投放对SEM的影响，客户会说“你们效果的提升要全指着我们的广告，那你们的价值如何体现 ? ”；如果我说“这是由于新上的一部分词效果不稳定造成的（或者任何一种同类解释）”，客户就会问“何时能恢复之前的效果？”实际上，我们都很清楚，只要客户不再投放广告，无论如何也无法恢复到之前的效果了。随着客户耐心的消失，换优化师是早晚会发生的结局。

那么，怎么避免出现这种情况呢？我的经验是，从初次给客户呈现数据时，就将数据按人群进行拆分，品牌人群，通用人群，竞品人群，潜在人群，等等。并且，给客户进行形象的描述。比如，品牌人群，可以说“这是对我们的品牌已经有所认知的人，点击我们广告，产生的后续行为数据，对于这些人群我们要极力维护我们品牌正面的形象，精彩的广告语，美观的广告图是我们的有力武器”；对于通用词，可以说“这是需要我们的产品，但还不知道选择什么品牌的客户，这些客户往往会对第一次选择的品牌建立极强的品牌忠诚度，是我们极力要争取的客户，同样，他们也是我们的竞争对手极力争取的，所以我们要和敌人进行正面的厮杀，CPC就是我们的武器”。当客户听到这样的数据解读时，往往会很有代入感，也觉得你好专业，对你的信任感爆棚，之后，对你的各种解释，也会做出更加正面的判断。

如果你一直如此给客户呈现数据，那么当遇到前面说的情况时，客户看到的是品牌人群数据先好后坏，通用人群的数据是基本稳定的，那么大可以这样解释“随着我们各渠道广告的停播，对我们品牌产生认知的人群数量出现下降，导致品牌类人群的推广效果出现了下降，这是正常情况，投放前后的数据也说明线下广告对我们的品牌认知起到了预期中的促进作用”。这时客户如果质疑你的说法，大可拿通用词的数据来进行说明：“虽然针对品牌人群的推广随着广告停播出现了效果下降，但在通用人群这个战场上，我们的战绩依然保持了稳定。”

当然，以上只是我个人这些年做SEM工作的经验总结，也许有同学有更好的方法，欢迎大家讨论。

IT瘾经验推荐

OpenClaw分享

拼多多20条运营小技巧

高转化率=快速起量

层级决定流量上限

店铺星级比消费者体验指标更重要

每日必做商品体检

超时发货=虚假发货

有活动好过没活动

ROI比成交出价更稳定

直通车千万别提示余额不足

日限额不要上来就无限额

三十天不出单链接尽快下架

发布相似品链接可以承接流量

截流就玩机会商品

定价=拼单价+限时限量购

讲解视频必须要传

链接断流不要慌

好品可以开运费险

起量速度=拖价节奏

好品才能长久运营

最好的防比价就是独家品

常规商家主要还是玩强付费

最后

5500篇新冠痊愈经验，告诉你阳了怎么办

更多阅读：

短视频运营该如何考核？

01 短视频运营的工作内容

02 绩效考核如何制定？

03 绩效考核的注意事项

1. 什么时候考核变现？

2. 考核要注重奖罚分明

3. 制定合理工资标准

4. 绩效没有过程检查与辅导

4步走，搭建好用的数据指标体系

一、清晰业务场景

二、清晰业务目标

三、梳理业务流程

四、确认数据采集

如何摆脱信息茧房？

一、信息茧房

1. 第一阶段

2. 第二阶段

3. 第三阶段

二、算法原理

三、孰是孰非

四、三个锦囊

1. 微调认知基模

2. 改善偏食情况

3. 多看多听多动手

五、总结一下

七问七答：亲历者讲阿里中台落地的实践

一、到底什么是中台？

二、我们公司有几十个开发，怎么做中台合适？

三、中台怎样落地？

1. 从哪里开始做？

2. 用什么方法？

四、互联网产品经理做中台的关键点？

五、还有什么要嘱咐的？

七年，我摸清了移动推广的所有套路

第一章：渠道

第二章：精准

第三章：内容

第四章：品效

大话后端开发的奇淫技巧大集合

模块化设计

通用服务抽离

架构独立服务

高并发优化

缓存：

异步

限流

服务降级

防刷/防羊毛党

并发问题

数据采集技巧（番外）

总结

京东亿级商品搜索核心技术解密

京东商品搜索简介

总体架构