Node-redis: خطوط الأنابيب

هل يتم ذلك من خلال أوامر client.multi و multi.exec؟

مرحبًا saritasa -

مرحبا بريس ،

1. أنا في حيرة من أمري ، ما هو الغرض من الوظائف "المتعددة" داخل node_redis إذن؟
2. ما هي الخوارزمية المستخدمة لتوجيه الأوامر تلقائيًا؟

شكرا،
ديمتري

العمليات المتعددة من مواصفات بروتوكول Redis ، ولها غرض معاملات خارج خطوط الأنابيب: http://redis.io/commands/multi

فيما يتعلق بكيفية عمل خطوط الأنابيب: http://redis.io/topics/pipelining ، هذه مجرد مسألة كتابة العميل لأوامر إلى Redis بالسرعة التي ترسلها بها دون انتظار الرد قبل كتابة الرد التالي. يتتبع العميل الأوامر المرسلة ثم يعيد تنظيم الردود بالأوامر المرسلة بمجرد رد Redis.

شكرًا بريس ، أفهم كيف يعمل http://redis.io/topics/pipelining . في تطبيق node.js - كيف ينبغي هيكلة الكود بحيث يتم توجيه الطلبات؟

لذلك في المثال أدناه

hgetall & expire - هل موصولة بالأنابيب أم لا؟ واحدة من المكالمات داخل رد الاتصال.

دالة getByID (جدول ، معرف ، التالي) {
إذا (! Success) إرجاع setTimeout (الوظيفة () {
getByID (جدول ، معرف ، التالي) ؛
} ، 2000) ؛

var end = utils.getEndTime(),
    base = getBase(),
    client = getClient(PK2str(table, id)),
    key = getHashID(table, id);

base.sismember(table, key, function (err, val) {
    if (err || !val) return next();

    client.hgetall(key, function (err, val) {
        if (err || !val) return next(new Error('Expired'), id);

        val = arrays_parse(table, val);
        next(null, val);
        client.expire(key, cfg.ttl.shards);

        if (!exports.silent) {
            profiler.log('cache', {
                'table': table,
                'id': key,
                'method': 'getByID',
                'data': val,
                'time': end()
            });
        }
    });  
});

}

يتم إرسال جميع الأوامر "موصلة بالأنابيب" ولكن لن يتم إرسالها في نفس إطار كتابة خط الأنابيب لسبب أو لسببين:

1. رد النداء الخاص بـ sismember هو ما يستدعي استدعاء hgetall - لذلك فأنت تمنع ضمنيًا هذه الأوامر من أن يتم ربطها ببعضها البعض لأي استدعاء عضو معين. لا يتم استدعاء رد الاتصال حتى يرد Redis.
2. إذا كان base و client عملاء Redis مختلفين ، فيمكنهم _NEVER_ مشاركة نفس خط الأنابيب.

يجب تنفيذ الأوامر من نفس السياق * لمعرفة أي فائدة من خطوط الأنابيب. على سبيل المثال ، مشابه لمثال PING في مستندات خطوط أنابيب redis:

// These commands will all be pipelined together:
client.ping()
client.ping()
client.ping()
client.ping(function () {
  // This would *NEVER* be in the same pipeline frame as the other four because it requires a reply to be received first
  client.ping()
})

* أو من سياقات منفصلة إذا تم إرسالها بشكل أسرع من رد Redis ، لكن لا ترد أبدًا على السياقات التابعة

حصلت عليه الآن - شكرا لك! هذا تعليق قيم جدا!

أعتقد أن node_redis "خطوط الأنابيب التلقائية" ليست خطوط الأنابيب المشار إليها بواسطة redis الرسمية.

هذه المرة تسمى RTT (ذهاب وإياب وقت). من السهل جدًا معرفة كيف يمكن أن يؤثر ذلك على الأداء عندما يحتاج العميل إلى تنفيذ العديد من الطلبات في صف واحد (على سبيل المثال إضافة العديد من العناصر إلى نفس القائمة ، أو ملء قاعدة بيانات بالعديد من المفاتيح). على سبيل المثال ، إذا كان وقت RTT هو 250 مللي ثانية (في حالة وجود ارتباط بطيء جدًا عبر الإنترنت) ، حتى إذا كان الخادم قادرًا على معالجة 100 ألف طلب في الثانية ، فسنكون قادرين على معالجة أربعة طلبات كحد أقصى في الثانية.
إذا كانت الواجهة المستخدمة عبارة عن واجهة استرجاع ، فإن RTT تكون أقصر بكثير (على سبيل المثال ، يبلغ مضيفي عن 0،044 مللي ثانية ping 127.0.0.1) ، لكنه لا يزال كثيرًا إذا كنت بحاجة إلى تنفيذ العديد من عمليات الكتابة على التوالي.

ما يعنيه خط الأنابيب بواسطة redis الرسمية هو الجمع بين أوامر متعددة وإرسالها مرة واحدة لمواجهة وقت الاستجابة بسبب RTT ، والذي لم يتم تناوله بواسطة node_redis. و "autoa pipelining" في node_redis يرسل في الواقع أكبر عدد ممكن من الأوامر في نفس الوقت باستخدام نموذج البرمجة غير المتزامن الخاص بـ Node.

هنا مقال جيد يناقش هذه المسألة. http://informatikr.com/2012/redis-pipelining.html

Vizwindsaritasa يستخدم كل من. multi و. دفعة الأنابيب كما هو مخطط له من الإصدار 2.2 وما بعده.