Neohope的网络笔记 – Page 18

打车软件功能拆解

Posted on 2021/05/07 by neohope — No Comments ↓

一个打车软件，基本需要以下功能：

一、乘客：
1、行程管理：乘客叫车、行程取消、历史行程查看
2、乘客上车引导
3、乘客与驾驶员聊天功能
4、乘客与驾驶员虚拟电话沟通功能
5、行驶轨迹展示、规划行驶路线展示
6、目的地修改
7、乘客支付
8、打赏功能
9、驾驶员评价功能
10、投诉功能
11、消息通知
12、紧急联系人，一键报警，行程分享

二、驾驶员：
1、车辆开始接单，车辆停止接单
2、车辆实时位置信息推送
3、抢单、订单查看、订单取消
4、车辆到达确认
5、驾驶员与乘客聊天功能
6、驾驶员与乘客虚拟电话沟通功能
7、乘客上车确认，开始计费
8、结束计费
9、乘客评价功能
10、收入查看、提现
11、申诉
12、消息通知

三、平台：
1、地理信息系统与车辆网格划分
按GeoHash将城市划分为多个网格，收到车辆位置后，将车辆更新到各个网格；
2、平台派单
根据乘客起始地点，在乘客所属网格，就近派单；
考虑用户习惯，价格、车况等；
不能让乘客长久等待，适时给驾驶员奖励；
给同一驾驶员单子要有好有坏；
不同驾驶员要雨露均沾，不能造成饥饿状态；
不同业务要用派单或抢单模式；
3、行驶路线规划
4、等待时长预估
5、计费规则设置、计费功能
6、车辆位置采集，车辆轨迹记录
7、车辆在线时长统计，车辆收入及行程数统计
8、发票管理、行程单管理
9、客服系统，客诉处理，工单系统对接
10、消息通知：
短信、微信、APP
11、信用系统：
乘客信用
驾驶员信用
黑名单
车辆信息审核
驾驶员信息审核
12、标签系统：
乘客标签及画像，个人乘车偏好
车辆标签及画像
驾驶员标签及画像
13、行驶安全：
驾驶员疲劳管理；
防疫信息管理；
行程录音取证分析；
AI自动分析异常情况，识别争吵、车辆路径偏离，车辆长期不移动等情况；
紧急情况处理，安全人员及警方及时介入，通知乘客安全联络人；
14、基础数据管理
用户、权限、角色、组织、城市、车辆管理、驾驶员管理
15、外部对接API
订单接收，订单确认或取消，行程推送，行程状态同步，计费推送，费用结算

四、业务扩展：
1、市场营销：卡券管理、优惠活动
2、增值业务：保险售卖、加油卡售卖
3、在专车之外，可以开展出租车、顺风车、拼车、预约用车、代驾、企业用户等业务
4、入口从APP扩展到公众号、小程序、其他打车平台、电话

记一次分布式锁引发的生产问题

Posted on 2021/04/30 by neohope — No Comments ↓

近期发版，要修复一个并发引起的主键冲突报警。

运维要求没有此类报警，组里同事顺手就改了。

结果第二天一早服务高峰期，服务直接卡死没有反应了。

快速定位到是这段代码的问题，回滚，解决问题。

然后分析了一下，开发、测试、架构都有问题：

原始逻辑：
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L2
4、服务B调用数据库服务入库
由于加锁逻辑比较特殊，并发时，会造成主键冲突。

问题逻辑：
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L1
4、服务B调用数据库服务入库
服务直接卡死，要么服务超时，要么锁超时，服务能不卡死吗

解决问题并不复杂，在这里就不罗嗦了。

问题是很简单，但暴漏的问题十分多：
1、开发对程序逻辑、分布式锁理解明显不够
2、在开发、测试、UAT环境下，开发和测试其实都发现了性能下降的问题，但都没有重视
3、架构和资深开发，代码审核工作问题也很大
其实很多时候，工具是一回事，但人员的专业性思维，其实更重要。

记一次HTTPS授权失败

Posted on 2021/02/01 by neohope — No Comments ↓

我们伟大的云提供商告诉我们，他们廊坊机房要关停了，要求我们迁移到其他机房，春节前一定要迁移完毕。

和运维、架构沟通后，做了迁移计划，做了演练，虽然时间仓促，问题特别多，但还是扛过去了。

迁移后，不少用户受到了影响，比如有一个省由于网络供应商问题，整个省的用户无法解析DNS。

这其中，印象最深的是，我们一个用户，服务、配置、权限各种都是正确的。但就是无法登录。

分析了几个小时，最后发现，原来是用户机器时间不对，时差有几个小时，在HTTPS请求到达防火墙时，就被干掉了。

设好时间，一切正常。

其实，之前也遇到过两三次类似问题，频率太低了，一开始根本就没考虑这种可能。

导致惨重代价的运维事故2021

Posted on 2021/01/10 by neohope — No Comments ↓

2021年12月：微软Azure日本东部地区故障
事件经过：因电力设备故障，导致Azure日本东部地区服务中断超5小时，影响大量企业客户业务。
事故原因：基础设施运维事故，电力设备故障。
造成损失：客户业务中断，微软按SLA赔付，声誉受损。

2021年12月：西安“一码通” 短短半月崩溃两次
事件经过：12月20日及次年1月4日，西安“一码通”系统在半个月内连续两次崩溃。特别是在全员核酸检测期间，系统无法显示健康码，导致检测点排起长龙。
事故原因：系统架构无法承载峰值流量。虽然有疫情压力，但从运维角度看，是缺乏有效的弹性扩容机制和流量削峰设计，系统在面对突增的并发访问时直接“熔断”。
造成损失：疫情防控关键环节“掉链子”，严重影响了城市的防疫效率和秩序。
相关事故：
2022年1月10日，广州“粤康码”崩溃。
2022年3月11日，上海“随申码”崩溃。

2021年11月：网易游戏机房过热宕机
事件经过：网易游戏机房温度过高触发报警，部分服务器过热宕机，空调重启后仍无法解决，多款游戏无法登录、断连，3小时后服务器恢复正常。
事故原因：机房制冷系统故障，温度失控。
造成损失：干扰玩家游戏体验，影响游戏运营口碑。

2021年10月：Facebook史上最严重宕机
事件经过：10月4日，Meta旗下Facebook、Instagram、WhatsApp等服务全球中断近7小时，创2008年以来最长纪录，员工门禁卡、邮箱也无法使用。
事故原因：内部运维操作失误，修改BGP路由规则时误删域名服务器IP地址块路由配置。
造成损失：影响全球数十亿用户，Facebook市值蒸发约600亿美元，险些引发第三方服务连锁崩溃。
小插曲：宕机期间，大量用户涌向了Twitter、Telegram等其他应用，又进一步导致这些应用程序的服务器崩溃。

2021年10月：微软Azure 虚拟机全球故障
事件经过：10月13日，微软Azure云服务发生长达6小时的严重中断。全球范围内的用户无法启动、创建或更新Windows虚拟机，甚至连管理界面都打不开。
事故原因：服务管理操作期间的调用故障。在进行后台维护操作时，系统内部的调用机制失效，导致控制平面（Control Plane）失灵，用户失去了对服务器的“控制权”。
造成损失：企业无法管理核心云资产，业务扩展和维护受阻，再次打击了企业对公有云稳定性的信心。

2021年10月：Roblox 历史最长宕机
事件经过：10月28日，全球热门游戏平台Roblox发生了一次长达73小时的严重宕机。作为“元宇宙”概念的代表，这次长时间的停服让数千万玩家无法登录。
事故原因：负载均衡器过载与架构瓶颈。由于平台流量激增，负责分配流量的负载均衡器不堪重负，引发了内部网络的拥塞。Roblox坚持自建数据中心而非完全上云的策略，在应对突发流量洪峰时暴露了弹性不足的问题。
造成损失：平台信誉受损，玩家流失，且引发了关于“关键业务是否该上公有云”的行业大讨论。

2021年8月：英国Telstra数据中心火灾
事件经过：澳大利亚电信巨头Telstra伦敦数据中心因UPS故障发生火灾，导致一半大楼断电，部分区域受损。
事故原因：UPS故障引发火灾，烧毁供电组件。
造成损失：严重影响依赖该数据中心的金融及企业客户业务运转。

2021年6月：Fastly 内容分发网络崩溃
事件经过：6月8日，CDN服务商Fastly出现严重故障，导致全球大量依赖其加速的网站（包括Amazon、Reddit、CNN、PayPal等）在近1小时内无法访问。
事故原因：服务配置修改触发系统漏洞。Fastly工程师在进行一项常规的“服务配置”修改时，意外触发了系统底层的一个未被发现的软件漏洞，导致其全球节点瞬间瘫痪。
造成损失：互联网“基础设施”级故障，大量主流网站同时“消失”，凸显了互联网供应链的脆弱性。

2021年5月：Salesforce 全球大规模宕机
事件经过：5月11日，全球最大的CRM服务商Salesforce遭遇长达5小时的服务中断。这次故障波及全球，导致大量销售和客服人员无法访问客户数据。
事故原因：运维人员“走捷径”引发连锁故障。一名工程师在进行配置变更时，使用了有缺陷的脚本去绕过标准流程。该脚本在重启服务器时发生超时失败，但由于自动化部署机制未停止后续操作，导致故障在各个数据中心不断扩散，最终压垮了系统。
造成损失：全球数百万依赖Salesforce的企业用户业务停摆，作为“云服务标杆”的可靠性形象受损。

2021年4月：美国WebNX犹他州数据中心火灾
事件经过：美国WebNX犹他州数据中心发生火灾，导致超360万个网站故障，约1.5万名客户资料受影响。
事故原因：UPS故障引发火灾，缺乏物理隔离导致火势蔓延。
造成损失：部分数据永久丢失，客户权益受损，企业声誉受创。

2021年3月：法国OVH斯特拉斯堡数据中心火灾
事件经过：3月10日，欧洲云计算巨头OVH位于法国斯特拉斯堡的数据中心发生火灾，燃烧6小时后被扑灭，4个数据中心中1座完全烧毁。
事故原因：疑似UPS故障或电力室逆变器周围湿气引发短路。
造成损失：发生起火的SBG2数据中心被完全烧毁，360万个法国政府及企业网站瘫痪，OVH面临巨额赔偿和客户流失。

为何医院数字化转型项目难以成功

Posted on 2020/12/12 by neohope — No Comments ↓

数字化转型，只能是一把手项目，除此之外注定失败。
国内多数的医院数字化转型项目，都是要求信息科来推进，医院领导和业务部门实际介入很少。
开局就十分不利。

产生这样局面的底层问题，在于两个：
1、组织架构老化
与欧美通常会有专业的CIO或CTO，中国多数医院的信息部门，受到的重视程度不够。
医院的信息科，其实主要就是一个运维部门，在医院组织架构中处于后勤部门一类。
这个组织架构已经几十年没变了，很难适应现代化的运营管理方法。
2、医院缺乏懂信息化的人才
国内多数的医院，十分缺乏懂业务、懂管理、懂IT技术的综合性管理人才。
直接导致了医院管理部门，与实际执行部门之间的脱节。
这样的人才不是没有，而是很稀少，且集中在顶级的那几家。
如果医院有这样的人，医院那真是捡到宝了。

再看看，中国多数医院信息科的现状（非顶级医院）：
1、相对业务科室是很弱势的
对于大科室、大专家和大主任，沟通的时候处于绝对的劣势地位，几乎没有任何话语权
2、人员数量和质量不匹配
信息科的人员，主要是桌面和运维人员，一般数量很少。
多数人员，对现代化的技术缺少理解和一手落地经验，难以挑起技术变革的大梁。
3、资源投入严重不足
效益好的医院：对比软件和安全的投入，多数医院仍倾向于基建和采购设备，因为会带来新的收入。
效益差的医院：绩效发放已经很困难，就更不愿意在这方面投入更多的资源。
加之多数医院都是风险厌恶型号机构，就更难有人愿意去做这种变革了。

那一般项目是如何落地的呢？
信息科协调不到院内资源，根本无法推动大刀阔斧的改革，没法动里子。
就只能借助院外资源，也就是厂商，做做面子。
但厂商和医院是很难平衡利益关系的：厂商利润很低，急着上线验收，医院如果再缺乏正确引导，很难有好的结果。
最后结果，同一口径，骂厂商无能。

一次macOS升级引发的灾难

Posted on 2020/11/29 by neohope — 2 Comments ↓

一、上周帮老婆大人把MacOS从Mojave升级到了Catalina，然后悲剧发生了。
任何需要截屏、屏幕共享或屏幕录制的应用都不能使用了，具体表现为：
1、配置-》安全与隐私里，多了一个选项”屏幕录制/Screen Recording”，里面列表是空的。
2、快捷键录屏是可以的
3、打开QuickPlayer，录制屏幕，提示之前禁用过屏幕录制，要求去修改权限；但由于列表是空的，根本无法做任何操作
4、其他APP，如微信、腾讯会议什么的，提示要增加权限，但“屏幕录制”里还是空的。

二、网上找了一下，无论国内国外，都有一些用户遇到了这个问题。尝试了一些建议的方法，搞不定。

#正常模式下，显示失败
sudo tccutil reset ScreenCapture

#恢复模式下，显示成功，重启后无效
tccutil reset ScreenCapture

三、于是打电话给Apple，一位妹子远程视频帮忙处理了很久，把能重置配置的方式都用了，还是不行。最后建议我重装系统。

四、重装，没任何变化。

五、把系统升级到了Big Sur，好歹有了一点儿进展：
1、配置-》安全与隐私里，”屏幕录制/Screen Recording”，里面列表是空的，但是新增任何APP都无效
2、快捷键录屏是可以的
3、QuickPlayer录制屏幕是可以的
4、其他APP，如微信、腾讯会议什么的，提示要增加权限，但“屏幕录制”里还是空的。

六、找了好长时间，最后终于解决了，步骤如下：
1、重启系统，听到提示音时，按下Command+R，进入恢复模式
2、恢复模式下，开启Terminal，禁用SIP服务 (system integrity protection)

csrutil disable

3、重启系统，进入正常模式，重命名tcc.db文件

sudo mv /Library/Application\ Support/com.apple.TCC/TCC.db /Library/Application\ Support/com.apple.TCC/TCC.db.bak

4、重启系统，进入恢复模式
5、恢复模式下，开启Terminal，启用SIP服务 (system integrity protection)

csrutil enable

6、重启系统，进入正常模式
7、你会发现问题解决了

整体来说，这应该是MacOS升级的一个Bug，出现频率并不高，而且横跨两个大版本至今没有解决。
（也可以这么说，Big Sur解决问题的方式只是把QuickTime加白名单了，根本没有解决根本问题；或者说解决问题的Apple程序员可能根本没有定位到问题产生的原因）

我自己解决这个问题花费了4个小时以上，如果没有编程经验的普通用户遇到，估计只能格式化重装了，希望Apple可以出个工具，解决此类问题，节约大家的时间。

记一次Excutor引发的生产故障

Posted on 2020/11/28 by neohope — No Comments ↓

当时看到《阿里巴巴Java编码规范》时，我感觉这里面说的不是大家都该知道的事情吗？真有必要汇总个规范出来？

出来混，总要还的，最近在老项目上就遇到了。

我们有两个服务，遗留项目，代码写的实在是不敢恭维。
用量其实不大，或者说偏小，但很默契的每两周挂一次，到今天是第三次了。

第一次OOM（没定位到根本问题）：
K8S网络组件异常，DNS解析失败，和架构一起排查后，发现问题如下：
1、系统原来使用过RabbitMQ，后来代码注释了
2、但POM中，还是有MQ的引用，别的不会做，但会启动MQ的监听
3、结果有一天K8S网络组件异常，DNS解析失败
4、MQ的心跳包瞬间起了几千个线程，连接找不到的MQ Server
5、服务挂了

推断的问题链路为：
DNS无法解析-》MQ心跳包不断起线程，而且没有连接池-》线程耗尽内存-》OOM-》服务挂掉

解决方法：
在POM中，干掉了MQ的引用，以为问题被修复了。

第二次OOM（大意了）：
1、表现仍是K8S网络组件异常，DNS解析失败
2、架构感觉容器DNS解析不了应该运维去查
3、只好拉上运维查，运维也比较给力，很快把日志给出来了
4、但是系统OOM时，并没有生成镜像，架构建议添加JVM参数，结果和运维排查后发现JVM参数已经加了，OOM应该有Dump啊
5、最后的结论是，非常规问题，等下次发生再解决
6、这个时候，已经感觉怪怪的了，问题根源根本没有找到啊，但大家都忙着机房搬迁，就没能跟下去（我的问题）

推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法：
碰运气，等下一次OOM生成Dump文件？我当时咋想的呢

第三次OOM（真的解决问题了吗？）：
1、感觉不对劲啊，为什么总是两周挂，于是拉取了日志
2、日志上没看出什么来
3、仍然没有OOM的Dump
4、jstack一看线程，傻眼了，一堆线程在waiting on condition
5、赶快看相关源码，居然是用了Excutor，然后线程和队列都是默认的
6、你懂的，线程数和队列默认几乎都是无限的，参数设置错误，导致线程池根本不会服用原来的工作线程
7、服务挂掉是早晚的事情

推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法：
修改Executor默认配置

咋说呢，再次认识到规范强制推行也是必要的，全靠人的个人水平，是不行的。他们的规范，恐怕也是各种坑汇总成的结晶吧。

记一次PG引发的生产故障

Posted on 2020/10/01 by neohope — No Comments ↓

前几天，突然收到报修，一个文件接收服务突然宕了。
我们运维同事很快就进行了重启，此时怪异的事情发生了：
重启服务后，服务一会儿就没响应了，端口可以通，文件全部上传失败，没有任何异常日志输出。

那就排查吧：
1、PG数据库连接正常，无死锁，表空间正常，数据查询秒回
2、服务配置几个月都没人改过，CPU、内存、存储、IO、网络，全部正常
3、上传客户端日志输出，显示其工作正常
4、只有文件接收服务，没有响应，也没有日志输出
初步判断，文件接收服务出问题了。

于是，新开一个云主机，重新安装服务，仍然无响应。
然后，拷贝了一个正常工作的主机，修改配置后，仍然无响应。
来来回回折腾了几个小时，还是不行。

无奈之余，试了一下向PG数据库插入数据，我去，几十秒都没有响应。
赶快问DBA，原来是做了高可用，主从库数据同步，从库异常了，导致主库可读不可写。
众人皆表示无奈，重启从库，问题解决。

其实，一开始就排查数据库了，但由于是生产库，只试过查询，没有试过写入。
但是，我们都大意了：
1、服务日志，输出不够详细，就算DEBUG打开，也不知道数据进行到哪一步了，这个最坑
2、没有正确的设置超时时间，原因是接收文件后，写入数据库一直在等待，服务日志没有任何数据库异常
3、数据库监视软件，只做了主库监视，根本没做从库监视
4、数据库主从配置，本应该是异步，但现在配置成了同步
5、没有监视主从库同步的情况
6、生产库，不敢轻易进行写操作，只看了查询效率及死锁，没有看慢语句

就这样一个小问题，绕过了层层监控机制，让问题排查十分困难，花费了大量的人力。
反思起来，如果只是为了记录日志而记录日志，但日志不能反应服务状态，那不如不记；如果只是为了监控而监控，但监控不到位，那不如不监控。
我们日常做事情，也是同样的道理，细节是魔鬼，把该把控的把控好了，才能提升效率，得到想要的结果。

快速提升单元覆盖率

Posted on 2020/09/19 by neohope — No Comments ↓

最近到新公司，接手了几十个老项目。由于项目特殊需要，需要快速将一个模块的单元测试覆盖率提升到80%以上。

怀着忐忑的心情看了一下，该模块居然还有一个单元测试，整体覆盖率为0，欲哭无泪啊。

手工写是来不及了，那就想办法自动生成吧。找了一下，最终决定采用EvoSuite。

EvoSuite有多种方式可以配置，包括命令行模式、Maven插件模式以、Eclipse插件模式、IDEA插件模式等。

一、maven模式
1、修改POM文件，在对应位置添加相关内容

<properties>
	<evosuiteVersion>1.0.6</evosuiteVersion>
</properties>

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>org.evosuite</groupId>
		<artifactId>evosuite-standalone-runtime</artifactId>
		<version>${evosuiteVersion}</version>
		<scope>test</scope>
	</dependency>
</dependencies>

<build>
	<pluginManagement>
		<plugins>
			<plugin>
				<groupId>org.eclipse.m2e</groupId>
				<artifactId>lifecycle-mapping</artifactId>
				<version>1.0.0</version>
				<configuration>
					<lifecycleMappingMetadata>
						<pluginExecutions>
							<pluginExecution>
								<pluginExecutionFilter>
									<groupId>org.apache.maven.plugins</groupId>
									<artifactId>maven-compiler-plugin</artifactId>
									<versionRange>[2.5,)</versionRange>
									<goals>
										<goal>prepare</goal>
									</goals>
								</pluginExecutionFilter>
								<action>
									<ignore />
								</action>
							</pluginExecution>
						</pluginExecutions>
					</lifecycleMappingMetadata>
				</configuration>
			</plugin>
		</plugins>
	</pluginManagement>
	<plugins>
		<plugin>
			<groupId>org.evosuite.plugins</groupId>
			<artifactId>evosuite-maven-plugin</artifactId>
			<version>${evosuiteVersion}</version>
			<executions>
				<execution>
					<goals>
						<goal>prepare</goal>
					</goals>
					<phase>process-test-classes</phase>
				</execution>
			</executions>
		</plugin>

		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.17</version>
			<configuration>
				<properties>
					<property>
						<name>listener</name>
						<value>org.evosuite.runtime.InitializingListener</value>
					</property>
				</properties>
			</configuration>
		</plugin>

		<!--plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>build-helper-maven-plugin</artifactId>
			<version>1.8</version>
			<executions>
				<execution>
					<id>add-test-source</id>
					<phase>generate-test-sources</phase>
					<goals>
						<goal>add-test-source</goal>
					</goals>
					<configuration>
						<sources>
							<source>.evosuite/evosuite-tests</source>
						</sources>
					</configuration>
				</execution>
			</executions>
		</plugin-->

		<plugin>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>3.8.1</version>
			<configuration>
				<source>1.8</source>
				<target>1.8</target>
			</configuration>
		</plugin>
	</plugins>
</build>

2、生成单元测试

mvn -DmemoryInMB=4000 -Dcores=4 evosuite:generate test

#生成的单元测试在
#.evosuite/best-tests
#拷贝到正确的路径就可以了

二、命令行模式
1、下载evosuite-1.0.6.jar包

Downloads

2、收集项目依赖，把evosuite-1.0.6.jar也放入target/dependency文件夹

mvn dependency:copy-dependencies

3、生成单元测试

cd target/dependency
java -jar evosuite-1.0.6.jar -help
java -Duse_separate_classloader=false -jar evosuite-1.0.6.jar -projectCP YOUR_CLASS_PATH -generateSuite -target ..\classes

#生成的单元测试在
#target/dependency/evosuite-tests
#拷贝到正确的路径就可以了

三、Eclipse插件模式
在eclipse中安装evosuite插件，需要额外的插件地址：
http://www.evosuite.org/update

四、单元覆盖率
1、插件安装
在eclipse中搜索并安装EclEmma Java Code Coverage插件，直接搜索即可

2、修改class loader配置

#默认使用单独的class loader，覆盖率会为0
separateClassLoader = true
#全局替换为
separateClassLoader = false

3、然后在项目上，右键，Coverage as-》JUnit Test
就可以看到覆盖率了哦。
我试过两个项目，一个简单的项目，覆盖率为95以上。
一个复杂一些的Web项目，覆盖率仅为30%左右。

五、总结
生成的单元测试，实际上没有什么维护性，如何用于生产环境，待探索。

TiDB环境搭建

Posted on 2020/06/27 by neohope — No Comments ↓

本节采用单机环境，搭建TiDB测试环境。
全程云环境部署，操作系统为CentOS7.6，用户为root。

1、修改ssh配置

# 提高连接数
vi /etc/ssh/sshd_config 
MaxSessions 20

#重启sshd
service sshd restart

2、安装tidb

# 系统更新
yum -y update

# 安装tidb源
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

# 安装tiup cluster
source .bash_profile
tiup cluster

3、新建cluster配置文件

# 新建配置文件
vi mytidb.yaml
# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
 user: "tidb"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"

# # Monitored variables are applied to all the machines.
monitored:
 node_exporter_port: 9100
 blackbox_exporter_port: 9115

server_configs:
 tidb:
   log.slow-threshold: 300
 tikv:
   readpool.storage.use-unified-pool: false
   readpool.coprocessor.use-unified-pool: true
 pd:
   replication.enable-placement-rules: true
 tiflash:
   logger.level: "info"

pd_servers:
 - host: 192.168.1.111

tidb_servers:
 - host: 192.168.1.111

tikv_servers:
 - host: 192.168.1.111
   port: 20160
   status_port: 20180

 - host: 192.168.1.111
   port: 20161
   status_port: 20181

 - host: 192.168.1.111
   port: 20162
   status_port: 20182

tiflash_servers:
 - host: 192.168.1.111

monitoring_servers:
 - host: 192.168.1.111

grafana_servers:
 - host: 192.168.1.111

4、应用cluster

#应用配置文件
tiup cluster deploy mytidb v4.0.0 ./mytidb.yaml --user root -i hwk8s.pem
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster deploy mytidb v4.0.0 ./mytidb.yaml --user root -i hwk8s.pem
Please confirm your topology:
TiDB Cluster: mytidb
TiDB Version: v4.0.0
Type        Host           Ports                            OS/Arch       Directories
----        ----           -----                            -------       -----------
pd          192.168.1.111  2379/2380                        linux/x86_64  /tidb-deploy/pd-2379,/tidb-data/pd-2379
tikv        192.168.1.111  20160/20180                      linux/x86_64  /tidb-deploy/tikv-20160,/tidb-data/tikv-20160
tikv        192.168.1.111  20161/20181                      linux/x86_64  /tidb-deploy/tikv-20161,/tidb-data/tikv-20161
tikv        192.168.1.111  20162/20182                      linux/x86_64  /tidb-deploy/tikv-20162,/tidb-data/tikv-20162
tidb        192.168.1.111  4000/10080                       linux/x86_64  /tidb-deploy/tidb-4000
tiflash     192.168.1.111  9000/8123/3930/20170/20292/8234  linux/x86_64  /tidb-deploy/tiflash-9000,/tidb-data/tiflash-9000
prometheus  192.168.1.111  9090                             linux/x86_64  /tidb-deploy/prometheus-9090,/tidb-data/prometheus-9090
grafana     192.168.1.111  3000                             linux/x86_64  /tidb-deploy/grafana-3000
Attention:
    1. If the topology is not what you expected, check your yaml file.
    2. Please confirm there is no port/directory conflicts in same host.
Do you want to continue? [y/N]:  y
+ Generate SSH keys ... Done
+ Download TiDB components
  - Download pd:v4.0.0 (linux/amd64) ... Done
  - Download tikv:v4.0.0 (linux/amd64) ... Done
  - Download tidb:v4.0.0 (linux/amd64) ... Done
  - Download tiflash:v4.0.0 (linux/amd64) ... Done
  - Download prometheus:v4.0.0 (linux/amd64) ... Done
  - Download grafana:v4.0.0 (linux/amd64) ... Done
  - Download node_exporter:v0.17.0 (linux/amd64) ... Done
  - Download blackbox_exporter:v0.12.0 (linux/amd64) ... Done
+ Initialize target host environments
  - Prepare 192.168.1.111:22 ... Done
+ Copy files
  - Copy pd -> 192.168.1.111 ... Done
  - Copy tikv -> 192.168.1.111 ... Done
  - Copy tikv -> 192.168.1.111 ... Done
  - Copy tikv -> 192.168.1.111 ... Done
  - Copy tidb -> 192.168.1.111 ... Done
  - Copy tiflash -> 192.168.1.111 ... Done
  - Copy prometheus -> 192.168.1.111 ... Done
  - Copy grafana -> 192.168.1.111 ... Done
  - Copy node_exporter -> 192.168.1.111 ... Done
  - Copy blackbox_exporter -> 192.168.1.111 ... Done
+ Check status
Deployed cluster `mytidb` successfully, you can start the cluster via `tiup cluster start mytidb`

#启用cluster
tiup cluster start mytidb
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster start mytidb
Starting cluster mytidb...
+ [ Serial ] - SSHKeySet: privateKey=/root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa, publicKey=/root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa.pub
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [ Serial ] - ClusterOperate: operation=StartOperation, options={Roles:[] Nodes:[] Force:false SSHTimeout:5 OptTimeout:60 APITimeout:300 IgnoreConfigCheck:false RetainDataRoles:[] RetainDataNodes:[]}
Starting component pd
        Starting instance pd 192.168.1.111:2379
        Start pd 192.168.1.111:2379 success
Starting component node_exporter
        Starting instance 192.168.1.111
        Start 192.168.1.111 success
Starting component blackbox_exporter
        Starting instance 192.168.1.111
        Start 192.168.1.111 success
Starting component tikv
        Starting instance tikv 192.168.1.111:20162
        Starting instance tikv 192.168.1.111:20161
        Starting instance tikv 192.168.1.111:20160
        Start tikv 192.168.1.111:20162 success
        Start tikv 192.168.1.111:20161 success
        Start tikv 192.168.1.111:20160 success
Starting component tidb
        Starting instance tidb 192.168.1.111:4000
        Start tidb 192.168.1.111:4000 success
Starting component tiflash
        Starting instance tiflash 192.168.1.111:9000
        Start tiflash 192.168.1.111:9000 success
Starting component prometheus
        Starting instance prometheus 192.168.1.111:9090
        Start prometheus 192.168.1.111:9090 success
Starting component grafana
        Starting instance grafana 192.168.1.111:3000
        Start grafana 192.168.1.111:3000 success
Checking service state of pd
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:37 CST; 13s ago
Checking service state of tikv
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
Checking service state of tidb
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:42 CST; 9s ago
Checking service state of tiflash
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:45 CST; 5s ago
Checking service state of prometheus
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:47 CST; 4s ago
Checking service state of grafana
        192.168.1.111      Active: active (running) since Thu 2020-07-02 11:38:47 CST; 4s ago
+ [ Serial ] - UpdateTopology: cluster=mytidb
Started cluster `mytidb` successfully

5、查看cluster状态

#查看cluster清单
tiup cluster list
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster list
Name    User  Version  Path                                         PrivateKey
----    ----  -------  ----                                         ----------
mytidb  tidb  v4.0.0   /root/.tiup/storage/cluster/clusters/mytidb  /root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa


#查看cluster详情
tiup cluster display mytidb
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster display mytidb
TiDB Cluster: mytidb
TiDB Version: v4.0.0
ID                   Role        Host           Ports                            OS/Arch       Status   Data Dir                    Deploy Dir
--                   ----        ----           -----                            -------       ------   --------                    ----------
192.168.1.111:3000   grafana     192.168.1.111  3000                             linux/x86_64  Up       -                           /tidb-deploy/grafana-3000
192.168.1.111:2379   pd          192.168.1.111  2379/2380                        linux/x86_64  Up|L|UI  /tidb-data/pd-2379          /tidb-deploy/pd-2379
192.168.1.111:9090   prometheus  192.168.1.111  9090                             linux/x86_64  Up       /tidb-data/prometheus-9090  /tidb-deploy/prometheus-9090
192.168.1.111:4000   tidb        192.168.1.111  4000/10080                       linux/x86_64  Up       -                           /tidb-deploy/tidb-4000
192.168.1.111:9000   tiflash     192.168.1.111  9000/8123/3930/20170/20292/8234  linux/x86_64  Up       /tidb-data/tiflash-9000     /tidb-deploy/tiflash-9000
192.168.1.111:20160  tikv        192.168.1.111  20160/20180                      linux/x86_64  Up       /tidb-data/tikv-20160       /tidb-deploy/tikv-20160
192.168.1.111:20161  tikv        192.168.1.111  20161/20181                      linux/x86_64  Up       /tidb-data/tikv-20161       /tidb-deploy/tikv-20161
192.168.1.111:20162  tikv        192.168.1.111  20162/20182                      linux/x86_64  Up       /tidb-data/tikv-20162       /tidb-deploy/tikv-20162

6、mysql客户端操作tidb

#安装源
wget https://repo.mysql.com//mysql80-community-release-el7-3.noarch.rpm
rpm -Uvh mysql80-community-release-el7-3.noarch.rpm

#安装mysql客户端
yum install mysql-community-client.x86_64

#登录tidb
mysql -h 192.168.1.111 -P 4000 -u root

#和普通mysql操作区别很小

7、查看tidb管理界面

# 性能监控
http://192.168.1.111:3000 
admin/admin

# 管理界面
http://192.168.1.111:2379/dashboard 
root/空