Node-redis: كيفية ضبط وقت انتهاء الصلاحية

يرجى التحقق من أوامر dcoumentation . يحتوي كل جزء على معلمة خاصة به ، لذا يمكنك كتابة شيء مثل:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

شكر

BridgeAR ارتباط التوثيق لا يعمل

لا يعمل .. نسخة ريديس 3.0

client.set(key, value, 'EX', 60 * 60 * 24, callback);

sxyjijiji إنه يعمل بشكل جيد بالنسبة لي. إذا واجهت خطأ ، فالرجاء نشر تتبع المكدس ووصف ما لا يعمل.

brucejcw لقد أصلحت الرابط

أعتقد أنه لم يتم تضمينه في وثائق node_redis ، حتى وظيفة المجموعة.
ربما يربك بعض الناس.

bruceCzK لا توجد وثائق أوامر صريحة. ولن تكون هذه فكرة جيدة بشكل عام حيث قد تتغير الأوامر في Redis ويمكن إضافة معلمات جديدة بمرور الوقت.

ولكن هناك أكثر من مرجع واحد للوثائق الرئيسية التي يجب عليك دائمًا الاطلاع عليها لمعرفة كيفية عمل الأوامر. إذا كنت ترى أي إمكانية لتحسين الوثائق الحالية ، فلا تتردد في فتح طلب سحب لها. قد تكون فكرة جيدة أن تضيف الارتباط على جميع تكرارات "الأوامر" في الملف README.md.

مرحبًا ، هل هناك طريقة لتعيين انتهاء الصلاحية الافتراضي على مستوى العميل؟

مثال: شيء من هذا القبيل

  const redisClient = redis.createClient({
    host: process.env.REDIS_ENDPOINT,
    port: process.env.REDIS_PORT,
    expire: 60 
})

مجرد ترديد أن هذا بناء جملة مربك للغاية ، خاصة للقادمين الجدد. لا يوجد شيء في وثائق node_redis حول انتهاء صلاحية المفتاح / TTLs. أتخيل أن معظم الأشخاص يستخدمون Redis كجزء من طبقة التخزين المؤقت وسيكون وقت انتهاء الصلاحية للمفاتيح جزءًا مهمًا حقًا من سير العمل هذا. IMO ، يجب أن يتم دمج هذا في واجهة برمجة التطبيقات الأساسية (ربما يمكن أن تأخذ الوظيفة set معلمة اختيارية) أو يجب أن تتحدث الوثائق على الأقل عن واجهة برمجة تطبيقات الأوامر من حيث صلتها بانتهاء صلاحية المفتاح.

يبدو أن الإجابة هي لا ، حيث لا يمكننا تعيين انتهاء صلاحية عالمية على مستوى العميل. من الممتع أن تضطر إلى تعيين انتهاء الصلاحية على كل مفتاح واحد.

ryanvanderpol تأخذ الوظيفة set بالفعل معلمة اختيارية كما هو موضح. مجرد إلقاء نظرة على الوثائق وتعليقي أعلاه.

@ kienpham2000 لا يوجد انتهاء صلاحية عالمي على مستوى العميل وسيكون من الصعب تنفيذه. يجب فحص كل أمر ومعالجته. بدلاً من ذلك ، يمكن لميزة جديدة لإضافة خطافات حل ذلك.
هذه ليست مكتبة تخزين مؤقت ومن المحتمل أنك تبحث عنها بدلاً من ذلك.

Bridgear : مفهوم ، لكنك نوعًا ما تفتقد هذه النقطة. ربما يكون هذا مجرد كسول ، لكنني أرفض تعلم واجهة برمجة تطبيقات Redis الأصلية بالكامل فقط حتى أتمكن من تثبيت الأشياء وسحبها. ربما لا يجب أن أستخدم مكتبة node_redis حينها. ربما يجب أن أستخدم شيئًا آخر يجلس فوقه ويلخص هذا بعيدًا عني. ومع ذلك ، كما قلت من قبل ، أعتقد أن معظم الأشخاص يستخدمون Redis كذاكرة تخزين مؤقت ولا يوجد شيء في وثائق node_redis يذكر كلمة "expire" أو "expiration" (أو حتى الأمر "EX" أو TTL) لذلك بدون البحث في وثائق Redis الرسمية ، يصعب فهم كيفية تعيين TTL فعليًا لمفتاح ، وهو إجراء أتوقع أن يتعين على غالبية الأشخاص القيام به.

ryanvanderpol إنها مكتبة عميل

إذا كنت تريد مكتبة ذاكرة تخزين مؤقت ، فيمكنك استخدام إحدى حزم npm العديدة المتوفرة ، مثل cacheman-redis أو node-redis-cache ، في وثائقهم ستجد إشارة صريحة لـ "expire": smile:

أتفهم وجهة نظرك ، لكنني أعتقد أنه لا ينبغي أن تكون مهمة node_redis تكرار توثيق Redis أو تجريد الأشياء بعيدًا أكثر من اللازم ...

CherryDT وجهة نظرك عادلة ، وهذا هو السبب أيضًا في أنني أعددت تعليقي السابق بعبارة "ربما يجب أن أستخدم شيئًا آخر يقع فوق node_redis" ، ولكن بالنظر إلى عدد إجراءات +1 التي تلقاها تعليقي حتى الآن ، فلا شك لدي أنني لست وحدي في هذا الإحباط.

إذا كان كل ما أردت فعله هو التواصل مباشرة مع Redis بتنسيق خام ، فإن هذا الغلاف لا يقدم قيمة كبيرة بالنسبة لي. أعتقد أنه من العدل تمامًا افتراض أن الغالبية العظمى من الأشخاص الذين يستخدمون Redis يفعلون ذلك لأغراض التخزين المؤقت وسيهتمون بانتهاء الصلاحية.

كان من الممكن إبطال هذه المحادثة بأكملها من خلال "نقطة جيدة ، يجب أن نضيف قليلاً إلى التوثيق حول كيفية تعيين انتهاء صلاحية المفاتيح ، إلى جانب بعض الأوامر الأخرى الشائعة الاستخدام". أفترض أنه يمكنني أيضًا تقديم PR لذلك أيضًا ، لكنني لست على دراية بـ Redis خارج استخدامه كذاكرة تخزين مؤقت.

بعد قولي هذا ، سألقي نظرة على المكتبات الأخرى التي ذكرتها ويمكنني الانتقال إلى واحدة منها بدلاً من ذلك إذا كانت تناسب حالة الاستخدام الخاصة بي بشكل أفضل.

نقطتي هي أن هناك وظائف أكثر بكثير من TTLs. هناك أنواع بيانات مختلفة (قوائم ، مجموعات ، مجموعات مرتبة) ، نظام ناشر ومشترك وغير ذلك ، وتكرار بشكل أساسي توثيق Redis (وإبقائه محدثًا) ، أو إضافة المزيد من السكر على المعلمات (والحفاظ على تحديثها). الأشياء التي أعتقد أنها خارج نطاق هذا العميل. لا أتوقع من عميل MySQL ميزات ORM (أو مرجع MySQL) أيضًا ، أليس كذلك؟

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

لذلك ، أوافق على أنه بالنسبة لحالة الاستخدام الخاصة بك ، ستكون أفضل حالًا مع وجود مكتبة "عالية المستوى" أعلى شيء مثل node_redis.

نعم ، أنا أختلف معك تمامًا هنا. أتوقع أن توضح لي الوثائق الخاصة بعميل MySQL كيفية القيام ببعض الأشياء الشائعة التي يقوم بها الجميع في MySQL ، مثل كيف أقوم بالاختيار باستخدام دالة مجمعة أو كيف أقوم باستعلام فرعي. لا أتوقع أن يشرح لي كيفية إنشاء ORM أو أن يكون نسخة من وثائق MySQL بأكملها ، لكن أرني كيف أفعل أشياء شائعة باستخدام المكتبة.

على أي حال ، من الواضح أنك لن ترى وجهة نظري وهذا مضيعة للوقت. حتى الآن ، يتفق معي 17 شخصًا ولا يوافقني أحد غيرك أنت وشخص آخر. لذا ، ربما يجب عليك التراجع والتفكير في كيفية رؤية الأشياء من منظور الآخرين من حين لآخر.

لماذا تجعل هذا شخصيًا؟ أفهم تمامًا وجهة نظرك ، أعتقد فقط أن node_redis ليست الأداة المناسبة للوظيفة في ذلك الوقت. (كما اتفقت مع نفسك قبل أن أبدأ حتى في توضيح وجهة نظري.) فكر في الأمر ، فإن إبقاء الأشياء صغيرة وقائمة بذاتها يبسط الكثير من الأشياء. قلق node_redis بشأن الشبكات ، أشياء مثل node-cache-redis (أو التنفيذ الخاص بك) تقلق بشأن استخدام Redis API بشكل صحيح. بهذه الطريقة ، لا يوجد الكثير من التبعيات. ستظل المكتبات "في الأعلى" موجودة دائمًا بطريقة أو بأخرى ، وبهذه الطريقة لا تحتاج node_redis إلى التحديث (أو حتى دعم إصدارات مختلفة من واجهة برمجة التطبيقات) في كل مرة يضيف فيها Redis بعض الميزات أو يغيرها (فقط عندما يضيف الأمر _command_ بالكامل) .

لقد قدمت لك حلولًا بديلة ، وآمل أن تلبي احتياجاتك ، وإذا لم يكن الأمر كذلك ، فاختر دقيقة للبحث عن "redis" على npm وستجد أيضًا العديد من المكتبات الأخرى.

دعنا نتفق فقط على أننا نختلف على هذا. (ولا يهم إذا وافق 17 أو 1700 شخصًا معك أو معي. أعتقد أنه يجب تقدير كل رأي.)

إذا نظرنا إلى السؤال الأصلي والإجابة ، لم أكن أعرف أنه يتعين علي استخدام .set() مع 'EX' وخيارات الوقت مثل تلك الموجودة في هذه المكتبة.

بالنظر إلى README.md الحالي ، فإنه يشرح كيفية استخدام client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback) ، ربما يمكننا إضافة بعض الحالات الأكثر شيوعًا لـ SET و GET بطريقة مماثلة؟ أفترض أيضًا أن الأشخاص يستخدمون الكثير من GET و SET مع redis.

لم أكن أدرك أن الكثير من الأشخاص لديهم مشكلات في ذلك لأن الإعجابات لا تظهر في صندوق الوارد الخاص بي.

سأكون جاهزًا للعلاقات العامة التي توثق الأمر set كمثال مع ذكر "expire" أيضًا.

أرغب أيضًا في الحصول على PR الذي يوثق أن هذه ليست مكتبة ذاكرة تخزين مؤقت ولا يقصد منها أن تكون واحدة. أنا منفتح على أي مدخلات حول كيفية تحسين التوثيق للأشخاص الجدد.

@ kienpham2000 حسنًا ، إنه أيضًا أمر منفصل - setex :)

فقط للتناغم هنا حول شرح _redis_ في الملف التمهيدي للوحدة _node_redis_. أنا لست مقتنعًا بالفكرة تمامًا. كما هو موضح في هذا المثال - استخدام set و expire في multi / exec ، باستخدام setex أو استخدام set مع "ex" - هناك العديد من الطرق للقيام بأشياء كثيرة. لا علاقة لأي منها بالعقدة. نشرح hgetall لأنه يبتعد عن كيفية إرجاع الأوامر الأخرى للقيم.

كي لا نقول إن الناس ليس لديهم أسئلة ، ولكن يبدو لي أن كتابة مدونة أو مشاركة وسيطة أو شيء ما هي طريقة أفضل لإعلام الناس بدلاً من التركيز عليها هنا. إذا حصلنا على السؤال ، فيمكن ربطه بأي مشكلات تظهر. قد يكون تحويل الملف التمهيدي للوحدة _node_redis_ إلى مصدر المعرفة أمرًا خارج النطاق.

stockholmux أنا فضولي فقط كيف نستخدم setex في هذا lib؟ هل هو فقط client.setex() ؟

إذا كان هذا lib هو تعيين 1-1 بأوامر redis ، فأعتقد أننا لسنا بحاجة إلى doc. ولكن إذا كان هذا lib يحتوي على واجهة برمجة تطبيقات خاصة أو طريقة فرق لتمرير الخيارات ، أعتقد أن وجود نوع من مستندات API سيكون مفيدًا جدًا للمطورين.

@ kienpham2000 هو تعيين 1 إلى 1. كان من المفترض دائمًا أن يكون واحدًا. عميل بسيط لاستخدام API. هذا مستوى منخفض وليس مستوى مرتفع.

و stockholmux محق في أن hgetall موثق فقط لأنه يمكنك استخدامه بطرق أكثر من أي أمر آخر. لكنها لا تزال تعيين 1 إلى 1.

على أي حال: أنا أؤيد إضافة قسم حول هذا الموضوع حتى لا يظهر ذلك مرة أخرى.

BridgeAR شكرًا رائعًا على مسودتي الأولى: https://github.com/NodeRedis/node_redis/pull/1229/files

تم التحديث: https://github.com/NodeRedis/node_redis/pull/1380

لقد وجدت هذا الآن ويبدو أنه طريقة أخرى: https://dzone.com/articles/tutorial-working-nodejs-and

لم أتمكن من تشغيل هذه الطريقة أيضًا (لا يوجد خطأ ، فقط بلا تأثير لذلك أنا أتخلى عن هذا المشروع وأقوم بالتبديل إلى https://www.npmjs.com/package/node-cache والذي يمكنه استخدام Redis على أي حال.

لا يمكن تعيين انتهاء الصلاحية ضمن طريقة "تعيين" باستخدام 'EX', 20 لأنك لا تقبل سوى معلمتين بدلاً من 3.

ربما لديك نسخة Redis قديمة؟ يقول المستندات أنه تمت إضافته في Redis 2.6.12: https://redis.io/commands/set

يمكنك استخدام SETEX بدلاً من ذلك ، والذي يوجد منذ 2.0.0 ...

ربما لديك نسخة Redis قديمة؟ يقول المستندات أنه تمت إضافته في Redis 2.6.12: https://redis.io/commands/set

أنا أستخدم redis في مشروع node-express ، مع JS غير ممكن لإضافة ثلاثة معلمات (أو لا أستطيع .. :-()

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); -> هذا هو الكود الخاص بي به خطأ في منطقة انتهاء الصلاحية.

ما هو إصدار Redis؟

Redis 2.4.5 لنظام windows

إذن ، من الواضح ، يرجى قراءة رسالتي أعلاه مرة أخرى والتحقق من وثائق Redis! تمت إضافة المعلمة "EX" في SET فقط في الإصدار 2.6.12 ، لذلك لا يحتوي الإصدار 2.4.5 من Redis عليها ، ولكن يمكنك بدلاً من ذلك استخدام SETEX الموجود منذ 2.0.0.

redis.setex(key, seconds, value)
redis.setex(key, value, seconds)

redis.setex(key, value, expiration) -> هذا لا يعمل

... لكنني وجدت طريقة واحدة صحيحة في هذا الرابط: نوافذ redis

إذا كنت تريد تغيير إصدار Redis الخاص بك ، نعم ، طريقك صحيح بالطبع.
إذا لم يكن الأمر كذلك ، فأنا أعمل أيضًا ، لقد أخطأت للتو في المعلمات (ولكن إذا كنت قد تحققت من مستندات SETEX ، فستلاحظ): إنها مفتاح ، ثوان ، قيمة وليس مفتاح ، قيم ، ثوان.

على أي حال ، من الرائع سماع أنه يعمل من أجلك الآن.

أدناه لا يعمل.

client.set('key', 'value', 'EX', 10, (error, replay)=>{
...
}

أي تحديث على هذا؟
أنا أستخدم client.expire(id,10) الآن.

ملاحظة: أنا أستخدم إصدار redis: Redis server v=5.0.0 وإصدار العقدة: v8.10.0

kdthanvi يجب أن يعمل. تحقق جيدًا مما يحدث بالفعل باستخدام MONITOR من redis-cli عند تشغيله.

kdthanvi على حق. لا يعمل مع redis 5:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

انت تحتاج:

"
client.set (مفتاح ، قيمة ، رد اتصال) ؛

client.expire (مفتاح ، TTL ، رد الاتصال) ؛
"

لجعلها تعمل بالفعل.

martinlevesque أعتقد أنك مخطئ. EX في الإصدار 2.6.12 وتجاوز node_redis 'EX' بشكل صحيح بغض النظر عن الإصدار. تحقق مع MONITOR وسترى.

يمكن أن يختلف SET + EXPIRE بشكل خطير عن SET .. EX بسبب الاختلافات الذرية.

نظرًا لأن هذا الموضوع هو رقم 1 عندما أبحث عن "انتهاء صلاحية مجموعة عقدة Redis" ، أود أن أجعلها نقطة لاستكمال الأمر التالي set expire الذي يعمل مع nodeJS redis اعتبارًا من اليوم.

setex(key, 60, value)

حيث 60 هو وقت انتهاء الصلاحية بالثواني.

نظرًا لأن هذا الموضوع هو رقم 1 عندما أبحث عن "انتهاء صلاحية مجموعة عقدة Redis" ، أود أن أجعلها نقطة لاستكمال الأمر التالي set expire الذي يعمل مع nodeJS redis اعتبارًا من اليوم.

setex(key, 60, value)

حيث 60 هو وقت انتهاء الصلاحية بالثواني.

تم العثور على هذا بعد ساعتين من التصحيح وحل الأخطاء. شكرا جزيلا لك ؛)