最近网站流量比之前大了一些，然后发现vercel的每个月100G流量可能不够用了，于是决定迁移到cloudflare pages。 虽然vercel界面更好看一些，然后自动部署也很方便，但是还是没有cloudflare pages不限流量香，并且自动部署github项目的操作流程也跟vercel一样。 然后把dns服务器也迁到cloudflare了，之前用的是porkbun，用porkbun主要是因为买域名便宜，然后api太拉了，还不知道为什么封了我的服务器ip，发邮件说被流量攻击了？ 然后果断迁移，还是大一些的服务商稳定一些。
感慨 打开了自己的博客，发现上一次写博客都是去年6月份了，居然都过去一年了。感慨之余，突然想写点什么，就写写刚刚想到的自建评论系统吧。 起因 之前博客的评论系统是用的disqus，不过总是有点问题，每一篇文章都可以看到所有的评论。然后又折腾了一下，换了现在的这个gitalk。大概看了一下，做得还是挺巧妙的，用github的issue在存储评论，然后用gitalk的评论来显示评论。这样省下了自建服务器。不过搜索了一下，没有找到自建评论系统的开源项目，而使用像disqus或者gitalk这种还是会有一些限制。感觉开发一个自建评论系统还是可以多一种选择。 设计 框架选择 设计的话会考虑前后端分离的方式，后端打算使用FastAPI+TortoiseORM，然后前端打算使用React，或者考虑只提供一个SDK，本来我前端也不擅长，估计弄出来也很丑。 数据库设计 erDiagram project { int id varchar name } project ||--o{ post : contains post { int id varchar title } post ||--o{ comment : contains comment { int id varchar content } user ||--o{ comment : submit user { int id varchar name varchar email } 用户 考虑接入Github和Google的oauth2，然后把用户的信息存储在数据库中。 实现 仓库地址 https://github.com/long2ice/talkit 暂时先创建一个仓库地址吧，后面有时间了再看。
简介 FastAPI-Admin 是一个基于 FastAPI 与 TortoiseORM 的开箱即用的后台管理面板，UI 框架使用了tabler，仅需要少量配置，即可快速搭建一个 CURD 管理台，类似于 Django Admin。 项目地址：https://github.com/fastapi-admin/fastapi-admin 线上 DEMO：https://fastapi-admin.long2ice.io/admin/login 用户名：admin 密码：123456 预览 特性 开箱即用，配置丰富。 集成登录、验证码、权限控制。 易于扩展，自定义。 内置多种组件，功能丰富的 CRUD 界面。 其它更多特性。 开发 FastAPI-Admin 基于 FastAPI 与 TortoiseORM，使用 jinja2 渲染前端界面。最早期的版本是使用前后端分离，通过 rest 协议进行通信，前端框架与查询协议直接来源于另一个开源项目，后来由于不便于扩展、不熟悉等原因放弃，并基于 tabler ui 开发了现在的版本。实现过程中参考了 Django Admin，通过后端进行资源配置，渲染菜单，界面等。并且实现了多种展示组件、编辑组件、筛选组件等。 除此之外，Pro 版本还实现了基于资源读写的权限控制，包括管理员、角色、权限三种对象。 文档 文档地址：https://fastapi-admin-docs.long2ice.io 目前英文文档更全面一些，中文文档还待编写中。
有一些计划中的，感兴趣，想做的一些开源项目，在此记录一下，以免遗忘。 trader 项目地址：https://github.com/long2ice/trader 用 Go 开发的一个加密货币自动交易框架，使用自定义策略进行买卖，最终从中获利，项目优先级略高，基本框架已经搭建好，后续准备支持更多的交易所以及合约。 rearq 项目地址：https://github.com/long2ice/rearq 一个 asyncio 的分布式异步任务执行框架，Fork 自另外一个项目，做了一些修改和提升，最终想做成类似于 celery 或者 airflow 那样，带有 api 与 web 界面的 asyncio 异步任务框架。 fastapi-admin 项目地址：https://github.com/long2ice/fastapi-admin 打算用react-admin作为前端重写一个版本，感觉这个似乎更完善，要是早知道的话就好了。 dataetl 项目地址：https://github.com/long2ice/dataetl 打算将synch翻译成 Go 语言实现，顺便学习 Go 语言，优先级不那么高，因为有了 trader 这个项目。 MiraiPy 项目地址：https://github.com/long2ice/MiraiPy 原本打算将MiraiGo这个项目翻译成 Python 实现，可惜没时间暂时搁置了。 aiomysqlreplication 项目地址：https://github.com/long2ice/aiomysqlreplication 原本想实现一个 asyncio 下的mysql-replication，也是没有时间与契机，暂时搁置。 其它 想实现一个 Go 下面的 ORM，因为感觉现在的一些 ORM 比如gorm太难用了，不过 Go 语言限制比较多，不如 Python 灵活，估计需要进一步调研以及技术沉淀。 tortoise-orm性能优化，可能需要学习一下 Cython，或者重写一个性能更高的 asyncio MySQL 驱动，类似asyncpg。
最近在项目中遇到了一个很奇怪的 bug，从发现到解决一共持续了一周左右的时间。 bug 现象：插入一条语句后在执行 select，会报查询不到记录，但是该 bug 只偶尔复现，频率很低。 刚开始的时候尝试了很多种方法，猜测是不是 ORM 框架问题，或者是 MySQL 版本问题，但是经过测试都不会复现。并且由于出现的概率很低，很不好 debug。 在问题的代码周围打了很多 log，也还是没有找到问题所在。 就在有一次我上厕所的时候灵机一动，联想到我们用的是阿里云的读写分离数据库，猜测是否是因为 MySQL 同步延迟导致的？ 查询了阿里云文档后，地址为https://help.aliyun.com/knowledge_detail/41767.html?spm=5176.11065259.1996646101.searchclickresult.3d3c31d8pXWGBr，最终确定正是这个问题。 解决方案有两种，一种是在同一事务中支持先写入再读取操作，另一种是使用单实例，放弃读写分离。