Freshworks的IT服务管理工具Freshservice使组织能够简化IT操作。Freshservice提供了支持ITIL的组件，可帮助管理员管理资产、事件、问题、更改和发布，而资产管理组件可帮助组织对其IT资产进行控制。Freshservice由rubyonrails提供支持Nginx乘客支持服务器托管在AWS的EC2实例上。这些服务器托管在四个数据中心上——美国东部（US）、欧洲中部（EUC）、印度（IND）和澳大利亚（AU）。MySQL中的UTF8我们的数据库和底层表都是用utf8编码创建的，以确保数据库级别也支持大多数字符。然而，MySQL的"utf8"编码只支持每个字符三个字节。真正的UTF-8编码每个字符最多需要4个字节。这个错误从未被修复过。2010年发布了一个解决方案：一个名为"utf8mb4"的新字符集。关于MySQL和UTF8的更多信息，您可以阅读"inmysql从不使用UTF8"的博客文章。Freshservice中的表情符号–Rails 3路Emojis是有效的UTF8字符，需要存储和检索4个字节。然而，由于MySQL本机UTF8编码的上述限制，我们无法在本机支持所有emojis。为了处理它们，我们依赖一个名为gemoji解析器的开源gem。gem允许通过将表情符号化为相关的文本表示，并在以后对其进行反标记，从而实现表情符号内容的序列化。为了安全地创建包含表情符号内容的票证，我们在保存前解析电子邮件内容，以检测表情符号化的每张票证的描述和注释内容。在显示票证信息时，我们没有去标记emojis（出于性能原因和客户不介意）；因此，票证在文本表示中包含emojis。例如，"？"被渲染为"：咧嘴笑："虽然我们在Rails 3上的设置起到了作用，但仍存在一些已知的挑战：宝石已经严重过时了。很多表情符号不能很好地与gem一起使用，并且以不可读的格式保存（例如，'\xF0\x9F\x98\x81…'），导致票证的布局被破坏。这就需要我们通过检查票证的描述和清除不可读的text/HTML部分来手动修复它。用新的emojis定期修补或更新gem并不是一个可行的长期解决方案。将电子邮件内容、票证描述和注释内容标记化会带来性能开销。如果我们按原样呈现emojis，那么在ticket list和details页面视图中，对每个罚单保存的主题和描述进行去标记化，则可能会带来性能开销。Rails 4中的表情符号rails4框架在内部更新了MySQL会话变量，并强制railsmysql以严格模式运行。有关Rails为什么强制执行这一点的信息，请参阅"在mysql中使用严格模式"。这些表是用utf8字符集和Unicode排序规则创建的，当向表中插入任何无效内容（在本例中是一个表情符号）时，MySQL会引发错误（错误的字符串值：第1行的列描述为"\xF0\x9F\x98\x81…"）。对于Freshservice团队来说，这是一个不可或缺的问题，因为任何包含表情符号的内容都会被系统丢弃。我们决定探索解决这个问题的可能办法。有几种方法可以解决这个问题。第一种选择是将所有富文本字段转换为Rails中的"可序列化字段"。Rails在内部使用YAML来序列化数据，默认的YAML解析器也能够序列化emojis。然而，这有一些问题。将字段更改为"serialized"将要求我们为所有现有记录运行一个数据更正脚本，因为它们将无法解析为YAML。其次，我们只是将序列化反序列化开销从数据库写入转移到数据库读取，这要糟糕得多。另一个选择是让Rails和MySQL完全使用utf8mb4编码集运行。然而，我们在多个数据中心的碎片上有数百个表，考虑到Freshservice的运行规模，迁移所有表是不可行的。另外，utf8mb4（4字节）列比传统的utf8（3字节）列占用更多的空间，数据库索引的长度限制为767字节。这意味着任何具有varchar（255）列的索引的表都会导致问题，因为以前占用255*3=765字节的索引现在将占用255*4=1020字节。这意味着我们必须更改索引中列的长度（对于我们所有的用例来说不是一个可行的解决方案），或者更新innodb large_前缀值并重新索引所有数据。无论哪种方式，更新索引都会花费太多时间，而且不值得这样做。我们决定测试一种更具反应性的方法。我们评估了在utf8mb4模式下运行Rails而不迁移任何数据库列。这意味着我们可以将Rails级别的编码设置为utf8mb4，并且只迁移一些表的特定列，以接受utf8mb4内容，并在将来将行为扩展到其他模块或表。要设置Rails在utf8mb4中运行，我们必须更新数据库.yml具体如下：默认值：默认值（&D）适配器：mysql2编码：utf8mb4游泳池：5发展：