0%

升级Hexo到v8.5.0之后,发现mathjax不能正确显示公式。看了下 文档 ,发现推荐的hexo renderer是hexo-renderer-pandoc,而目前使用的是hexo-renderer-kramed,而且这个包已经不再更新也不推荐使用了。

卜算子自嘲 丁元英

本是后山人, 偶做前堂客。 醉舞经阁半卷书, 坐井说天阔。

大志戏功名, 海斗量福祸。 论到囊中羞涩时, 怒指乾坤错。

# 提升Hexo NexT主题加载速度 中留了个尾巴,优化到最后发现最影响PageSpeed Insights得分的竟然是Google Auto Ads。 这里 有个有意思的讨论,说加上auto ads之后页面加载得分显著变低,采纳答案说“你啥也做不了,也不用care”,下面有人反对这个观点,加载速度评测认为网站慢就会导致搜索排序降低。我赞成后者的观点,风一样的加载速度即我所欲也,本来无一物,何处惹尘埃!

说起牛肉面,第一反应可能是“兰州拉面”。可兰州人民已经澄清了这个概念:兰州没有拉面,只有牛肉面。去 甘肃旅游 时也吃过正宗的兰州牛肉面,确实不错。帝都的兰州拉面馆不少,个人觉得马华的还原度就挺高。

最近折腾博客比较多,也看了不少使用Hexo博主所用的评论系统,觉得Valine不错,NexT也天然支持(配置也就简单)。正想切换时发现它存在安全性问题,于是就调研了一下可用的评论系统,简单总结:

希望在Hexo的NexT主题中增加自定义分类的菜单,即一个指向特定分类的链接,且页面显示的是类似主页的标题+摘要风格。 定制Hexo分类页面布局

之前有一个比较粗暴的实现: # Hexo添加自定义分类菜单项并定制页面布局 。由于直接修改了源码,属于侵入式实现,导致以后升级Hexo和主题时需要手动再改代码,不推荐。

Hexo的NexT主题可以天然支持友链,即在NexT主题的配置文件_config.yml中有一个# Blog rolls块,可以添加友链,然后在左边栏的底端会显示它们。但这样的问题在于边栏的空间有限,友链比较多的话会影响布局,而且分散主题。于是考虑单独创建一个友链页面,搜索发现已经有成型的方案,大体思路与 # Hexo添加自定义分类菜单项并定制页面布局 一样,增加菜单项和友链模版,再修改主页模板。这样做可以解决问题,但是不够优雅,属于侵入式的定制(直接修改了主题文件模板),但绝大多数人都采用了这种方案 :-)。

最近一直想简化每篇博客的永久链接,现在的永久链接大概长这样:

/2021/03/21/migrateopsmanager.en/

希望能把中间的日期去掉,变成这样:

/migrateopsmanager.en/

原因在于短链接更作为标识更为合理,而URL上带有日期字符串并没有实际的用处,除非重名的博客太多。但这不可能发生,因为所有博客都写在source/_post文件夹,博客重名会引起文件名冲突。

生产环境有个SQL Server云数据库,花钱不少,性能却很差。最近发现跑一些并不太复杂的存储过程却需要好几分钟。其中一个常用的存储过程是将几张表通过一个键值关联并返回结果,这几张表都在千万级大小。分析了下执行计划,发现index seek花去了90%以上的时间,进而发现这些表的索引碎片化都极为严重。由于这个老DB几经易手,没人知道这些表和存储过程是做什么的,于是需要手动分析这些表的schema和存储过程所依赖的表。基于这些结果再对索引重建提升性能。下面就是用来分析DB的一些重要Query。

.NET中使用MongoDB非常简单,一般来说可以直接使用BsonDocument,也可以使用定义好的数据类型对文档进行CRUD操作。本文通过实例对比一下两种方式的优劣,通常,通过强类型Collection对文档进行操作更为便捷。

MongoDB事务是个很好的功能,但对于高并发场景下的多文档事务,写冲突难以避免。一个写冲突的实例:

Exception: Command update failed: Encountered error from mongodb.svc.cluster.local:27017 during a transaction :: caused by :: WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction..

在一个分片MongoDB集群上并发执行transaction时遇到许多MongoCommandException错误: code 251, codename NoSuchTransaction:

Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 5. Command find failed: cannot continue txnId 4 for session 38604515-2584-45a5-a17a-5eb5d34ea6c4 - = with txnId 6. Command insert failed: cannot continue txnId 31 for session 3ed7ea61-eae1-440f-8d95-b6e066b35b69 - = with txnId 34.

本文为系列第五部分,用生成的自签名证书打开userdb的TLS和AUTH,并且完成userdb的公网域名访问。

整个系列:

  1. 安装MongoDB Ops Manager
  2. 创建用户数据库(replicaset)
  3. 用户数据库服务配置公网访问
  4. openssl生成自签名CA证书和server证书
  5. 打开用户数据库TLS通信加密和Auth授权

理解不同层面的TLS加密

开始之前,先解释下部署中不同层面的TLS加密:Secure Connections to Ops Manager, Secure Connections to Application Database, Secure Connections to MongoDB Deployments,我们需要的是最后一个,Enable TLS to MongoDB Deployments。而且这个配置不能直接通过界面完成,因为需要将生成的自签名证书“上传”到userdb的每个server上,然后才能配置这些证书所在的路径。

本文为系列第四部分,相对独立,先生成一个自签名CA证书,然后生成MongoDB各个server证书。

整个系列:

  1. 安装MongoDB Ops Manager
  2. 创建用户数据库(replicaset)
  3. 用户数据库服务配置公网访问
  4. openssl生成自签名CA证书和server证书
  5. 打开用户数据库TLS通信加密和Auth授权

自签名证书不推荐在生产环境使用,虽然它可以保证通信过程中的加密,但不能避免中间人攻击。Public Key Infrastructure (PKI)相关的内容也不在本文的讨论范围,这里假设读者对PKI已有基本的认识。

本文为系列第二部分,使用第一部分安装好的MongoDB Ops Manager创建用户数据库。

整个系列:

  1. 安装MongoDB Ops Manager
  2. 创建用户数据库(replicaset)
  3. 用户数据库服务配置公网访问
  4. openssl生成自签名CA证书和server证书
  5. 打开用户数据库TLS通信加密和Auth授权

所谓的Application Database是MongoDB Ops Manager的后端DB,并不能用来存放用户数据,所以我们需要用Ops Manager创建用户数据库。使用Ops Manager创建的MongoDB叫做Deployment,注意此DeploymentMongoDB Deployment,与kubernetes的Deployment不是一码事。

MongoDB的入门配置门槛(单机)很低,但如果想达到生产环境的要求则有些技术含量。生产环境的配置要求包括Replica Set、Sharding、Scale up/down、数据备份、通信加密TLS和指标实时监控等。配置这些功能比较繁琐,有不少坑要踩。那么有没有好用的工具帮我们配置和管理呢?