摘要：
# 业务背景 有这样一个场景，数据供应商定期提供一次海量的数据，把这些数据存储到 Hadoop hive 中去，但是这些数据和我们系统是不通用的，需要先进行分析以便于我们的系统能够识别这些数据，具体的分析过程省略，最后生成一个 mapping 关系数据，存储着两边的标志 key 和数据的生命周期。 阅读全文
摘要：
「借鉴学习计划」的核心是：复制一份别人的学习计划到自己的计划中，并同步推送学习任务给自己，并且每个操作都要发送通知给对方。 它们的类图如下： 它们的关系是一对多： 按照 DDD 的思路，业务应该发生在领域层中，事件也是从领域中触发的，整个流程的可读性比较强，下面以借鉴功能为例： 阅读 ：首先不能借鉴 阅读全文
摘要：
之前在 Safari 上用 事件来实现 下拉菜单，结果在 iOS 上不兼容。 尝试了 MDN 和 stack over flow 上各种奇技淫巧，然而在 iOS 上全都败下阵来。 孙子兵法云：上兵伐谋。看来正面不行，就要侧面来。 与其针对 iOS Safari 这个怪物，不如来次釜底抽薪，永绝后患。 阅读全文
摘要：
angular 启用 ssr 之后，访问一个不存在的地址时响应中的状态码也是 200，这可能会导致搜索引擎收录 404 页面，不利于 SEO。 解决这个问题要从 SSR 的原理开始， node(express 服务) angular 路由 angular 对应的模块 有可能请求后端服务获取数据 渲染 阅读全文
摘要：
最近在开发记录感想功能的时候用到了1对1的数据关系，具体情况是这样的，有这样两个1对1的类型 它们的1对1关系配置如下： 是软删除的，这里配置了一个 然后我们用 命令构建数据库，生成的脚本如下： 再造一条数据，方便测试 不出意外的话，这个 的`Id 1` 业务代码如下： 就是对 的`Item Not 阅读全文
摘要：
终于把统计服务实现了，测试并发布上线。观察了几天 Redis 的内存开销，访问量大约每天 800 万，基本维持在 150 MB 以下，数据库的压力也有明显下降。 仔细复盘这个架构，存在一个缺点：由于 Watcher 从 中 一个 Key，Pop 是随机的，所以有可能把新加入 的 给 出来了，而我们的 阅读全文
摘要：
之前，统计每篇博文的阅读数的方式是经过筛选去重之后直接更新数据库，并发压力直接传导到数据库，假设1秒有1000个并发请求，传统方案会在1秒内并发进行1000次数据库更新操作。 为了降低数据库的并发压力，需要重新设计统计服务。思路是即使1秒有1万个并发请求，也只是依次更新数据库，对数据库没有并发压力。 阅读全文
摘要：
跌跌撞撞的走完了本命年，些许风雨些许晴。 这一年来，遇过过很多问题，两种问题最为头疼，最难的问题是没有认识到这是个问题，一旦能够意识到这是个问题，处理起来还是不难的。 例如，去年年初那段时间，有个负责上传图片的服务，运行一段时间后就无法继续上传图片了，花了很多时间去定位问题，解决问题，但是始终无法修 阅读全文
摘要：
背景 每个动作都会生产一条动态数据，如今已经生成了一千多万条数据，而且正以每天好几万的速度迅速增长，频繁的读写导致 RDS 数据库实例压力非常大，该库还有核心业务的数据，为了避免对核心数据的影响，决定将其分出来。 结合其业务特点，决定使用 MongDB，那么第一个问题就是如何同步这些数据了。 方案一 阅读全文
摘要：
在之前的版本中滚动条位置是一个大问题，主要表现在 1. 使用快捷键或者手势前进/后退的时候，滚动条的位置经常是错乱的，所以只能每个页面都要重置一个滚动条的位置； 2. #anchor1 锚点位置无法定位 2017年10月开始解决这个问题，历时7个月终于在 6.1 beta1 中解决了。 解决方案就是 阅读全文