经历了一些杂事

引入新技术TIDB

手上有个项目,数据量异常庞大, 然后又需要关系型数据库的支持, 在一轮的选择之后, 最后选定tidb。 tidb是个很新的项目, 各个方面都不是很稳定, 一堆的bug, 一堆的坑. 但是对大数据的处理方式实在诱人. 在去年年底的时候, 在测试环境搭建起来, 今年上正式环境, 遇到的一堆的问题, 主要是tidb对服务的IO性能要求非常高, 阿里云的ESC就是渣, 然后是新的运维接手部署, 遇到挺多问题, 后面再tidb的开发帮助下, 解决了问题. 后面邀请了TIDB的人到我们公司做讲座, 效果挺好. 后面我们会将一些比较重要的东西, 迁移到tidb, 估计是一件有趣的事情.

发布新数据

上个项目开发的时候, 留下了一个比较大的坑, 导致不得不维护了一套新的数据. 本来去年就因该发布的, 由于产品的各种原因, 现在都没法发, 结果就是, 开发人员维护了两套代码, 运营人员维护了两套数据, 都是伤啊o(╥﹏╥)o

第一次发布失败

准备发布新版本

  • web组备份所有数据, 合并代码, 删除旧的数据库, 上线新的数据库, 切换代码, web组发布完毕
  • C++ 生成服务器开始发布, 拉最新的板块数据, 生成历史, 发布新版行情数据
  • C++ 业务服务器开始发布, 拉取最新的数据, 生成业务数据, 发布新版业务数据
  • 客户端开始接收新的数据

问题:
数据跳空, 无法解决

准备回滚:

  • 删除新的数据库, 还原旧的数据, 结果数据量太大, 导致卡顿了三个小时
  • 回滚代码
  • C++ 全部回滚

总结: 发布新版的时候, 就不要把原来的数据库也删除了, 直接创建一个新的数据库, 然后把代码也全部备份一遍, 这样就能做到秒级回滚

第二次发布数据

在解决问题后, 我们重新选择了一个时间进行发布, 有了前面的经验, 发布很成功.

开始有点乱

项目有点多, 穿插比较厉害, 做事情感觉没有原来精细了, 有点草草了事的感觉. 这种感觉很不爽, 却又不知道怎么解决, 感觉转管理后, 有点膨胀了.

发表评论

电子邮件地址不会被公开。 必填项已用*标注