<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Lua on KK的博客</title><link>https://spin6lock.github.io/tags/lua/</link><description>Recent content in Lua on KK的博客</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Wed, 16 Oct 2024 00:00:00 +0800</lastBuildDate><atom:link href="https://spin6lock.github.io/tags/lua/feed.xml" rel="self" type="application/rss+xml"/><item><title> 又溢出了</title><link>https://spin6lock.github.io/2024/10/16/%E5%8F%88%E6%BA%A2%E5%87%BA%E4%BA%86.html</link><pubDate>Wed, 16 Oct 2024 00:00:00 +0800</pubDate><guid>https://spin6lock.github.io/2024/10/16/%E5%8F%88%E6%BA%A2%E5%87%BA%E4%BA%86.html</guid><description>&lt;p&gt;海外上线了，首日无事故，总算平平安安。最近抓了个黑产，发现又是熟悉的溢出，&lt;a href="https://spin6lock.github.io/2023/09/16/%E9%A1%B9%E7%9B%AE%E4%B8%8A%E7%BA%BF%E5%95%A6.html"&gt; 和旧文如出一辙 &lt;/a&gt;，真是尴尬&lt;/p&gt;&#10;&lt;p&gt;这次遭殃的是交易行，也是利用相乘后，一个巨大的数量变成一个小的消耗，刚刚好可以负担得起，于是他就上架了庞大数量的虚拟货币(153722867280914*120000)，一直卖一直拿钱 …… 同样的，检查的地方也只是不让负数通过，没有留意到上限，哎，十分尴尬&lt;/p&gt;</description></item><item><title> 项目上线啦</title><link>https://spin6lock.github.io/2023/09/16/%E9%A1%B9%E7%9B%AE%E4%B8%8A%E7%BA%BF%E5%95%A6.html</link><pubDate>Sat, 16 Sep 2023 00:00:00 +0800</pubDate><guid>https://spin6lock.github.io/2023/09/16/%E9%A1%B9%E7%9B%AE%E4%B8%8A%E7%BA%BF%E5%95%A6.html</guid><description>&lt;p&gt;历时 3 年半，项目终于上线啦，打开 tig 翻到仓库的开头，看看提交历史，还是有点感慨的，实在没想到要花这么久。简单聊点线上问题吧&lt;/p&gt;&#10;&lt;p&gt;这次上线最刺激的是，开服前半小时，发现昨晚压测的服务器崩掉了，原因是聊天服务内存太大导致 OOM。于是用 memlimit 紧急止血，出问题的方法挂到模块上方便后续线上热更，然后打包，重启，紧赶慢赶在开服前几分钟搞完，提前开服错峰。真的非常非常刺激，当然，线上也没有出现这个问题，我们压测的例子相对比较极端，一大堆人每 30 秒集体跳场景，注册场景聊天的地方又做了锁来保序，平台响应聊天只要有点延迟，就会导致堆积，超时设的 10 秒也有点太长了&lt;/p&gt;</description></item><item><title> 代码扫描</title><link>https://spin6lock.github.io/2022/08/12/%E4%BB%A3%E7%A0%81%E6%89%AB%E6%8F%8F.html</link><pubDate>Fri, 12 Aug 2022 00:00:00 +0800</pubDate><guid>https://spin6lock.github.io/2022/08/12/%E4%BB%A3%E7%A0%81%E6%89%AB%E6%8F%8F.html</guid><description>&lt;p&gt;最近犯了一个很蠢的错，Code Review 的时候觉得非常丢人，决心不再犯第二次了，同样的错误不再犯第二次，才能不断进步XD 于是写了个小工具来检查。但是实际跑起来，才发现 Lua 这里设计得不太好，留下了一个合法但很容易犯错的坑&lt;/p&gt;</description></item><item><title>Lua54 兼容性</title><link>https://spin6lock.github.io/2021/07/13/Lua54%E5%85%BC%E5%AE%B9%E6%80%A7.html</link><pubDate>Tue, 13 Jul 2021 00:00:00 +0800</pubDate><guid>https://spin6lock.github.io/2021/07/13/Lua54%E5%85%BC%E5%AE%B9%E6%80%A7.html</guid><description>&lt;p&gt;最近在搞迁移，准备将项目依赖的 Lua 5.3 迁移到 5.4 上面去，先翻译一下手册的第八章，强迫自己读完，&lt;a href="https://www.lua.org/manual/5.4/manual.html#8"&gt; 原文地址 &lt;/a&gt;&lt;/p&gt;&#10;&lt;p&gt;这里我们列出了从 Lua 5.3 迁移到 Lua 5.4 可能会遇到的兼容性问题&lt;/p&gt;</description></item><item><title>skynet 中隐藏的单点服务 : Harbor</title><link>https://spin6lock.github.io/2020/01/22/skynet%E4%B8%AD%E9%9A%90%E8%97%8F%E7%9A%84%E5%8D%95%E7%82%B9%E6%9C%8D%E5%8A%A1.html</link><pubDate>Wed, 22 Jan 2020 00:00:00 +0800</pubDate><guid>https://spin6lock.github.io/2020/01/22/skynet%E4%B8%AD%E9%9A%90%E8%97%8F%E7%9A%84%E5%8D%95%E7%82%B9%E6%9C%8D%E5%8A%A1.html</guid><description>&lt;p&gt;昨晚和同事一起看 skynet 的代码，对于 skynet 实现的按名字发送消息比较好奇，走读了一下代码，特意写篇文章记录一下&lt;/p&gt;&#10;&lt;p&gt;Skynet 服务间通信，比较常用的是 &lt;code&gt;skynet.send&lt;/code&gt;，该接口在 &lt;code&gt;skynet/lualib/skynet.lua&lt;/code&gt; 中，实现则是 &lt;code&gt;skynet.core&lt;/code&gt; 模块的 send 方法。&lt;code&gt;skynet.core&lt;/code&gt; 是 skynet 提供给 lua 的一个 so，代码在 &lt;code&gt;skynet/lualib-src/lua-skynet.c&lt;/code&gt;，它用了一个巧妙的注册办法：&lt;code&gt;luaopen_skynet_core&lt;/code&gt;，将自己注册成 &lt;code&gt;skynet.core&lt;/code&gt; 了。它提供的 send 方法就是 C 代码里的 &lt;code&gt;lsend&lt;/code&gt;，也就是 &lt;code&gt;send_message&lt;/code&gt; 方法。对于目标服务地址是字符串的，就会用 &lt;code&gt;skynet_sendname&lt;/code&gt; 实现发送&lt;/p&gt;</description></item></channel></rss>