实测人数小于10w时无性能压力。
概括原理是利用session_id 鉴别与统计用户身份

- 阅读剩余部分 -

备忘，当对一个有唯一索引字段的表做插入操作INSERT INTO 时做遇到冲突则更新的逻辑ON DUPLICATE KEY UPDATE。
想知道此时是否仍然能够获取到 操作的行的id值db.lastrowid？

sql = "INSERT INTO `mTable`(`id`, `tfsn`)  " \
          "VALUES(%s, %s) " \
          "ON DUPLICATE KEY UPDATE `tfsn`=VALUES(`tfsn`);"

vals = (id, tfsn)

try:
    db.execute(sql, vals)

    new_cid = db.lastrowid
    print("tfid:", tfid) #如果触发了update 可以获得id值?

结论是，能，也可能不。
当触发update 有内容变更时，可以获得 id值；
当update的内容新旧完全一致前后没有变化的话，mysql会认为没有任何行被更新。所以返回的 id 会是0

2月份自我隔离在家的时候就计划给 R2S 加显示屏，一直在忙其他项目到今天才拿起电烙铁。即便网上已有大量复制黏贴的经验教程，还是踩了不少坑。以下是备忘。

先上个最最基本的调通的成果界面

- 阅读剩余部分 -

Okay长话短说。实际上有点标题党，因为最终的解决方啊并非直接用纯PHP实现了旧版word文件的处理。
由于时间已经不早了，为了争取续命睡眠的时间，我会在项目做的差不多之后在回顾之时补完这篇日志。

需求背景

由于甲方的一些客观条件约束。有一大批原始素材内容是旧版word格式(.doc) 。希望能直接从固定格式的文档内提取和整理内容导入数据库。
服务端环境为linux

备选方案

1. PHP自身的扩展 php_com_dotnet.dll
2. PHP的第三方插件PHPWord
3. PHP调用服务器的第三方程序antiword
4. 和上一个解决方案类似，后端用Python 跑一个服务监听待处理word文档队列，异步处理。

在可行性研究阶段目前已经否决了前3种方案，正在用第四种方法迂回实现需求。

- 阅读剩余部分 -

详细公告见 https://magnetwork.io/mag-goes-stellar/

团队改为集成到XLM链的主要考虑是目前币圈的氛围比较冷淡，担忧维护独立主链节点数量不足会造成链易分叉易受攻击滚动慢的缺陷。

集成的方式是使用相同团队开发的 移动端 stellar钱包 LITEMINT 激活其中的magnet资产（需要存入至少2 XLM）获得mag地址后把mag存入，会自动转换为 mag token。

可以理解为swap，但实际上XLM链上的 mag 是可以双向流动的，可以反向发往mag钱包；
在开发者担心的mag链健康状况恶化发生以前，mag钱包和节点仍可以长时间正常运作包括节点奖励和 Pos奖励；
LITEMINT钱包内的 MAG同样支持Pos奖励；

前景虽然悲观，但这个swap措施看出开发者态度还是很积极的。
2019寒冬仍未散去，抱团取暖也许不是一个坏主意。