【问题标题】:client state and database updates with pubnub使用 pubnub 进行客户端状态和数据库更新
【发布时间】:2013-09-02 12:39:57
【问题描述】:

我目前有一个使用 Netty/MySQL 构建的服务器,我正在对其进行优化。它非常简单,基本上做了以下事情:

  • 接受持久连接
  • 代表客户端进行数据库查询(取决于客户端消息和授权)
  • 更新客户端状态(现在每个客户端/通道使用局部变量 - 即“numberOfQueriesMadeForThisClientSession”)
  • 根据数据库、身份验证和其他客户端的知识强制断开连接(即,如果客户端 A 已连接并且客户端 B 发送特殊命令,如果通过服务器验证,则客户端 A 断开连接)
  • 对断开连接做出反应(更新数据库等)
  • 检查 aes 加密的内容

但是,我有点担心缩放可能发生的事情类型......例如,也许可以优雅地处理超时断开连接,而不是用户实际退出或强制断开连接、竞争条件等。

很可能 pubnub 已经通过比我自己更多的测试来考虑这个东西......所以我想知道 - 迁移我的 netty/mysql 服务器以使用 pubnub 的基本结构是什么?乍一看,在我看来,pubnub 是一个纯粹的消息中继,没有任何数据库或业务逻辑处理......?

选择的语言是 PHP,但此时我对基本架构最感兴趣

【问题讨论】:

    标签: php architecture pubnub


    【解决方案1】:

    好的 - 现在我已经考虑过了,我认为它对于我的特定用例是完全可行的,但 Pubnub 并不是真正设计为使用(或需要)额外的持久服务器。

    通过使用唯一的频道名称并保留订阅/发布密钥,可以采用不同的方法,这与传统的服务器模型不同。

    也可以通过“超级客户端”订阅/处理/发布来完成,但在我看来,这有点让事情回到原点。

    我对自己和其他人的建议——以完全不同的方式考虑 pubnub(和类似服务),并尽可能避免使用 持久“超级客户端”/服务器 :)

    【讨论】:

    • 我们确实有客户成功地将通过 PubNub 发送的所有消息保存到他们自己的数据库中。我们还在努力使 fan-in(多对 1)更容易完成。这里的一些提示可能会有所帮助:stackoverflow.com/questions/19823483/…
    • PubNub BLOCKS is released 2016 Q4 时重新考虑您的 PubNub 评估。我确信它会使您的解决方案易于实施、非常健壮且非常可扩展。
    猜你喜欢
    • 1970-01-01
    • 2020-11-30
    • 2021-11-10
    • 2018-04-05
    • 2017-06-01
    • 2018-09-28
    • 1970-01-01
    • 2011-06-08
    • 1970-01-01
    相关资源
    最近更新 更多