Nutritious Pancake Mountain


    0.2.3 • Public • Published

    quick-pomelo logo

    Build Status Dependencies Status

    Scalable, Transactional and Reliable Game Server Framework based on Pomelo and MemDB

    Performance and Scalable

    • Fast in-memory data access.
    • Distributed architecture, system capacity is horizontally scalable. Performance can be linearly increased by simply add more servers.

    Distributed ACID Transaction

    • ACID(Stands for Atomicity, Consistency, Isolation, Durability) transaction support on distributed environment.
    • Data atomicity and consistency guarantee, never leave dirty data in memory.
    • Concurrency and locking control, which make it very easy to write concurrency code. High performance on concurrent system.

    High Availability

    • Each server is backed by one or more replica, no single point of failure.

    MVC Architecture

    • Simple and clear Module-Controller architecture.
    • Use Mongoose to define data models.

    ES6 Promise Supported

    • Promise A+ compatible
    • Support ES6 generators (yield)

    Powerful Built-in Modules

    • Very powerful built-in modules, like push module. You can build a full featured push/chat service with almost zero code.


    Quick Start



    Quick-pomelo is based on pomelo, have a draft idea of pomelo framework is required.


    Quick-pomelo use memdb for underlaying data storage, so understanding memdb is required.

    Install dependencies

    sudo npm install -g memdb-server
    • Install pomelo globally
    sudo npm install -g rain1017/pomelo

    Start with template

    First copy the template to your working directory. The template contains most common skeletons for a quick-pomelo game server.

    Define models

    Define data models in app/models directory

    // app/models/player.js
    module.exports = function(app){
        var mdbgoose = app.memdb.goose;
        var PlayerSchema = new mdbgoose.Schema({
            _id : {type : String},
            areaId : {type : String},
            teamId : {type : String},
            connectorId : {type : String},
            name : {type : String},
        }, {collection : 'players'});
        mdbgoose.model('Player', PlayerSchema);

    Write controllers

    Write controllers in app/controllers directory

    // app/controllers/player.js
    var Controller = function(app){ = app;
    var proto = Controller.prototype;
    proto.createPlayerAsync = function(opts){
        // Get model by[model]
        var player = new;
        yield player.saveAsync();
    proto.removePlayerAsync = function(playerId){
        var player = yield;
            throw new Error('player not exist');
        yield player.removeAsync();
    module.exports = function(app){
        return new Controller(app);

    Define routes

    For each type of server, write a route in app/routes directory.

    // app/routes/player.js
    module.exports = {
        // Routing in handler
        handler : function(session, method, msg){
            // Return a string routing key
            // Same routing key always route to the same backend server.
            return session.uid || msg.playerId;
        // Routing in remote
        remote : function(routeParam, method, args){
            return routeParam;

    Write server handlers

    Write server handlers in app/servers/[server]/handler

    // app/servers/player/playerHandler.js
    var Handler = function(app){ = app;
    Handler.prototype.createPlayer = function(msg, session, next){
        // Get controller by[controler]
    module.exports = function(app){
        return new Handler(app);

    Start server

    Before start

    • Make sure Redis and MongoDB has started.
    • Copy ./config/memdb.conf.js to ~/.memdb/ (mkdir if not exist)
    • Start memdb cluster
    memdbcluster start

    Start server

    pomelo start --harmony

    Well done! Congratulations!

    Quick's Philosophy

    A typical realtime game server framework is stateful for the sake of performance, all states is kept in server local memory. However, this approach has significant drawbacks:

    • Any exceptions (may be caused by bugs or unexpected client input) may result in non-consistent state (half-modified dirty data), which is very difficult to recover
    • Concurrency control is very difficult to implement
    • We must remember which server the data is located, and use rpc to get data, which is error prone.
    • In memory data will be lost on server failure, it's very difficult to support HA

    Thanks to MemDB, quick pomelo un-invent the stateful approach and use a web server like 'MVC' based architecture. All servers become stateless and all states is stored in memdb. You can now get all benefits from a typical stateless web server, without losing performance and scalability of in memory stateful server.


    Copyright 2015 rain1017.

    Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

    Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. See the AUTHORS file for names of contributors.


    npm i quick-pomelo

    DownloadsWeekly Downloads






    Last publish


    • rain1017