سنشرح في هذا الفيديو نظام إداة قواعد البيانات غير العلائقية Redis، حيث سنشرح لماذا قد نفكر باستخدام قواعد بيانات Redis والفائدة منها.

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

سنُقدِّم في هذه المقالة حل تمرين مقالة استخدام قاعدة بيانات Redis لحفظ البيانات. بعد ذلك، سنُحلِّل أداء خوارزمية فهرسة صفحات الإنترنت، ثم سنبني زاحفَ ويب Web crawler بسيطًا.

المفهرس المبني على قاعدة بيانات Redis

سنُخزِّن هيكلي البيانات التاليين في قاعدة بيانات Redis:

• سيُقابِل كلَّ كلمة بحثٍ كائنٌ من النوع URLSet هو عبارةٌ عن مجموعة Set في قاعدة بيانات Redis تحتوي على مُحدِّدات الموارد الموحدة URLs التي تحتوي على تلك الكلمة.
• سيُقابِل كل مُحدّد موارد موحد كائنًا من النوع TermCounter يُمثّل جدول Hash في قاعدة بيانات Redis يربُط كل كلمة بحث بعدد مرات ظهورها.

يُمكِنك مراجعة أنواع البيانات التي ناقشناها في المقالة المشار إليها، كما يُمكِنك قراءة المزيد عن المجموعات والجداول بقاعدة بيانات Redis من توثيقها الرسمي.

يُعرِّف الصنف JedisIndex تابعًا يَستقبِل كلمة بحثٍ ويعيد مفتاح كائن الصنف URLSet المقابل في قاعدة بيانات Redis:

private String urlSetKey(String term) {
    return "URLSet:" + term;
}

كما يُعرِّف الصنفُ المذكور التابع termCounterKey، والذي يستقبل مُحدّد موارد موحدًا ويعيد مفتاح كائن الصنف TermCounter المقابل في قاعدة بيانات Redis:

private String termCounterKey(String url) {
    return "TermCounter:" + url;
}

يَستقبِل تابع الفهرسة indexPage محددَ موارد موحدًا وكائنًا من النوع Elements يحتوي على شجرة DOM للفقرات التي نريد فهرستها:

public void indexPage(String url, Elements paragraphs) {
    System.out.println("Indexing " + url);

    // أنشئ كائنًا من النوع‫ TermCounter وأحصِ كلمات الفقرات النصية

    TermCounter tc = new TermCounter(url);
    tc.processElements(paragraphs);

    // أضف محتويات الكائن إلى قاعدة بيانات‫ Redis
    pushTermCounterToRedis(tc);
}

سنقوم بالتالي لكي نُفهرِّس الصفحة:

1. نُنشِئ كائنًا من النوع TermCounter يُمثِل محتويات الصفحة باستخدام شيفرة تمرين المقال المشار إليه بالأعلى.
2. نُضيف محتويات ذلك الكائن في قاعدة بيانات Redis.

تُوضِّح الشيفرة التالية طريقة إضافة كائنات النوع TermCounter إلى قاعدة بيانات Redis:

public List<Object> pushTermCounterToRedis(TermCounter tc) {
    Transaction t = jedis.multi();

    String url = tc.getLabel();
    String hashname = termCounterKey(url);

    // إذا كانت الصفحة مفهرسة مسبقًا، احذف الجدول القديم
    t.del(hashname);


    // أضف مدخلًا جديدًا في كائن الصنف‫ TermCounter وعنصرًا جديدًا إلى الفهرس
    // لكل كلمة بحث
    for (String term: tc.keySet()) {
        Integer count = tc.get(term);
        t.hset(hashname, term, count.toString());
        t.sadd(urlSetKey(term), url);
    }
    List<Object> res = t.exec();
    return res;
}

يَستخدم هذا التابع معاملةً من النوع Transaction لتجميع العمليات، ثم يرسلها جميعًا إلى الخادم على خطوة واحدة. تُعدّ تلك الطريقة أسرع بكثير من إرسال متتاليةٍ من العمليات الصغيرة.

يمرّ التابع عبر العناصر الموجودة في كائن الصنف TermCounter، ويُنفِّذ التالي من أجل كل عنصرٍ منها:

1. يبحث عن كائنٍ من النوع TermCounter -أو ينشئه إن لم يجده- في قاعدة بيانات Redis، ثم يضيف حقلًا فيه يُمثِل العنصر الجديد.
2. يبحث عن كائنٍ من النوع URLSet -أو ينشئه إن لم يجده- في قاعدة بيانات Redis، ثم يضيف إليه محدّد الموارد الموحد الحالي.

إذا كنا قد فهرَسنا تلك الصفحة من قبل، علينا أن نحذف كائن الصنف TermCounter القديم الذي يمثلها قبل أن نضيف المحتويات الجديدة.

هذا هو كل ما نحتاج إليه لفهرسة الصفحات الجديدة.

طلبَ الجزءُ الثاني من التمرين كتابةَ التابع getCounts الذي يَستقبِل كلمة بحثٍ ويعيد خريطةً تربط محددات الموارد الموحدة التي ظهرت فيها تلك الكلمة بعدد مرات ظهورها فيها. انظر إلى تنفيذ التابع:

    public Map<String, Integer> getCounts(String term) {
        Map<String, Integer> map = new HashMap<String, Integer>();
        Set<String> urls = getURLs(term);
        for (String url: urls) {
            Integer count = getCount(url, term);
            map.put(url, count);
        }
        return map;
    }

يَستخدِم هذا التابعُ تابعين مساعدين:

• getURLs: يَستقبِل كلمة بحثٍ ويعيد مجموعةً من النوع Set تحتوي على محددات الموارد الموحدة التي ظهرت فيها الكلمة.
• getCount: يَستقبِل محدد موارد موحدًا URI وكلمة بحث، ويعيد عدد مرات ظهور الكلمة بمحدد الموارد المُمرَّر.

انظر تنفيذات تلك التوابع:

    public Set<String> getURLs(String term) {
        Set<String> set = jedis.smembers(urlSetKey(term));
        return set;
    }

    public Integer getCount(String url, String term) {
        String redisKey = termCounterKey(url);
        String count = jedis.hget(redisKey, term);
        return new Integer(count);
    }

تَعمَل تلك التوابع بكفاءةٍ نتيجةً للطريقة التي صمّمّنا بها المُفهرِس.

تحليل أداء عملية البحث

لنفترض أننا فهرسنا عددًا مقداره N من الصفحات، وتوصلنا إلى عددٍ مقداره M من كلمات البحث. كم الوقت الذي سيستغرقه البحث عن كلمةٍ معينةٍ؟ فكر قبل أن تكمل القراءة.

سنُنفِّذ التابع getCounts للبحث عن كلمةٍ، يُنفِّذ ذلك التابع ما يلي:

1. يُنشِئ خريطةً من النوع HashMap.
2. يُنفِّذ التابع getURLs ليسترجع مجموعة مُحدِّدات الموارد الموحدة.
3. يَستدعِي التابع getCount لكل مُحدِّد موارد، ويضيف مُدْخَلًا إلى الخريطة.

يستغرق التابع getURLs زمنًا يتناسب مع عدد محددات الموارد الموحدة التي تحتوي على كلمة البحث. قد يكون عددًا صغيرًا بالنسبة للكلمات النادرة، ولكنه قد يكون كبيرًا -قد يَصِل إلى N- في حالة الكلمات الشائعة.

سنُنفِّذ داخل الحلقة التابعَ getCount الذي يبحث عن كائنٍ من النوع TermCounter في قاعدة بيانات Redis، ثم يبحث عن كلمةٍ، ويضيف مُدخْلًا إلى خريطةٍ من النوع HashMap. تستغرق جميع تلك العمليات زمنًا ثابتًا، وبالتالي، ينتمي التابع getCounts في المجمل إلى المجموعة O(N)‎ في أسوأ الحالات، ولكن عمليًا، يتناسب زمن تنفيذه مع عدد الصفحات التي تحتوي على تلك الكلمة، وهو عادةً عددٌ أصغر بكثيرٍ من N.

وأما فيما يتعلق بتحليل الخوارزميات، فإن تلك الخوارزمية تتميز بأقصى قدرٍ من الكفاءة، ولكنها مع ذلك بطيئةٌ لأنها ترسل الكثير من العمليات الصغيرة إلى قاعدة بيانات Redis. من الممكن تحسين أدائها باستخدام معاملةٍ من النوع Transaction. يُمكِنك محاولة تنفيذ ذلك أو الاطلاع على الحل في الملف RedisIndex.java (انتبه إلى أن اسمه في المستودع JedisIndex.java والله أعلم).

تحليل أداء عملية الفهرسة

ما الزمن الذي تستغرقه فهرسة صفحةٍ عند استخدام هياكل البيانات التي صمّمْناها؟ فكر قبل أن تكمل القراءة.

لكي نُفهرِّس صفحةً، فإننا نمرّ عبر شجرة DOM، ونعثر على الكائنات التي تنتمي إلى النوع TextNode، ونُقسِّم السلاسل النصية إلى كلمات بحثٍ. تَستغرِق كل تلك العمليات زمنًا يتناسب مع عدد الكلمات الموجودة في الصفحة.

نزيد العدّاد ضمن خريطة النوع HashMap لكل كلمة بحثٍ ضمن الصفحة، وهو ما يَستغرِق زمنًا ثابتًا، ما يَجعَل الصنف TermCounter يَستغرِق زمنًا يتناسب مع عدد الكلمات الموجودة في الصفحة.

تتطلَّب إضافة كائن الصنف TermCounter إلى قاعدة بيانات Redis حذف كائنٍ آخرَ منها. يستغرِق ذلك زمنًا يتناسب خطّيًّا مع عدد كلمات البحث. بعد ذلك، علينا أن نُنفِّذ التالي من أجل كل كلمة:

1. نضيف عنصرًا إلى كائنٍ من النوع URLSet.
2. نضيف عنصرًا إلى كائنٍ من النوع TermCounter.

تَستغرِق العمليتان السابقتان زمنًا ثابتًا، وبالتالي، يكون الزمن الكليُّ المطلوبُ لإضافة كائنٍ من النوع TermCounter خطيًا مع عدد كلمات البحث الفريدة.

نستخلص مما سبق أنّ زمن تنفيذ الصنف TermCounter يتناسب مع عدد الكلمات الموجودة في الصفحة، وأن إضافة كائنٍ ينتمي إلى النوع TermCounter إلى قاعدة بيانات Redis تتطلَّب زمنًا يتناسب مع عدد الكلمات الفريدة.

ولمّا كان عدد الكلمات الموجودة في الصفحة يتجاوز عادةً عدد كلمات البحث الفريدة، فإن التعقيد يتناسب طردًا مع عدد الكلمات الموجودة في الصفحة، ومع ذلك، قد تحتوي صفحةٌ ما نظرًيًا على جميع كلمات البحث الموجودة في الفهرس، وعليه، ينتمي الأداء في أسوأ الحالات إلى المجموعة O(M)‎، ولكننا لا نتوقَّع حدوث تلك الحالة عمليًّا.

يتضِّح من التحليل السابق أنه ما يزال من الممكن تحسين أداء الخوارزمية، فمثلًا يُمكِننا أن نتجنَّب فهرسة الكلمات الشائعة جدًا، لأنها أولًا تحتل مساحةً كبيرةً من الذاكرة كما أنها تستغرِق وقتًا طويلًا؛ فهي تَظهرَ تقريبًا في جميعِ كائناتِ النوعين URLSet و TermCounter، كما أنها لا تحمل أهميةً كبيرةً فهي لا تساعد على تحديد الصفحات التي يُحتمَل أن تكون ذاتَ صلةٍ بكلمات البحث.

تتجنَّب غالبية محركات البحث فهرسةَ الكلماتِ الشائعةِ التي يطلق عليها اسم الكلمات المهملة stop words ضمن هذا السياق.

اجتياز بيان graph

إذا أكملت تمرين مقالة "تنفيذ أسلوب البحث بالعمق أولًا باستخدام الواجهتين Iterables و Iterators"، فلديك بالفعل برنامجٌ يقرأ صفحةً من موقع ويكيبيديا، ويبحث عن أول رابطٍ فيها، ويَستخدِمه لتحميل الصفحة التالية، ثم يكرر العملية. يُعدّ هذا البرنامج بمنزلةِ زاحفٍ من نوع خاص، فعادةً عندما يُذكرُ مصطلح "زاحف إنترنت" Web crawler، فالمقصود برنامج يُنفِّذ ما يلي:

• يُحمِّل صفحة بداية معينة، ويُفهرِس محتوياتها.
• يبحث عن جميع الروابط الموجودة في تلك الصفحة ويضيفها إلى تجميعة collection.
• يمرّ عبر تلك الروابط، ويُحمِّل كلًّا منها، ويُفهرِسه، ويضيف أثناء ذلك روابطَ جديدة.
• إذا عَثَر على مُحدّدِ مواردَ مُوحدٍ فهرَسَه من قبل، فإنه يتخطاه.

يُمكِننا أن نتصوّر شبكة الإنترنت كما لو كانت شعبة graph. تُمثِل كل صفحة إنترنت عقدةً node في تلك الشعبة، ويُمثِل كل رابط ضلعًا مُوجّهًا directed edge من عقدةٍ إلى عقدةٍ أخرى. يُمكِنك قراءة المزيد عن الشعب إذا لم تكن على معرفةٍ بها.

بناءً على هذا التصور، يستطيع الزاحف أن يبدأ من عقدةٍ معيّنةٍ، ويجتاز الشعبة، وذلك بزيارة العقد التي يُمكِنه الوصول إليها مرةً واحدةً فقط.

تُحدِّد التجميعة التي سنَستخدِمها لتخزين محددات الموارد المحددة نوع الاجتياز الذي يُنفِّذه الزاحف:

• إذا كانت التجميعة رتلًا queue، أي تتبع أسلوب "الداخل أولًا، يخرج أولًا" FIFO، فإن الزاحف يُنفِّذ اجتياز السّعة أولًا breadth-first.
• إذا كانت التجميعة مكدسًا stack، أي تتبع أسلوب "الداخل آخرًا، يخرج أولًا" LIFO، فإن الزاحف يُنفِّذ اجتياز العمق أولًا depth-first.
• من الممكن تحديد أولويّاتٍ لعناصر التجميعة. على سبيل المثال، قد نرغب في إعطاء أولوية أعلى للصفحات التي لم تُفهرَس منذ فترة طويلة.

تمرين 12

والآن، عليك كتابة الزاحف، ستجد ملفات الشيفرة التالية الخاصة بالتمرين في مستودع الكتاب:

• WikiCrawler.java: يحتوي على شيفرة مبدئيّة للزاحف.
• WikiCrawlerTest.java: يحتوي على اختبارات وحدة للصنف WikiCrawler.
• JedisIndex.java: يحتوي على حلِّ تمرينِ مقالة استخدام قاعدة بيانات Redis لحفظ البيانات.

ستحتاج أيضًا إلى الأصناف المساعدة التالية التي استخدَمناها في تمارين المقالات السابقة:

• JedisMaker.java
• WikiFetcher.java
• TermCounter.java
• WikiNodeIterable.java

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

نفِّذ الأمر ant build لتصريف ملفات الشيفرة، ثم نفِّذ الأمر ant JedisMaker لكي تتأكّد من أنه مهياٌ للاتصال مع خادم Redis الخاص بك.

والآن، نفِّذ الأمر ant WikiCrawlerTest. ستجد أن الاختبارات قد فشلت؛ لأن ما يزال عليك إتمام بعض العمل أولًا.

انظر إلى بداية تعريف الصنف WikiCrawler:

public class WikiCrawler {

    public final String source;
    private JedisIndex index;
    private Queue<String> queue = new LinkedList<String>();
    final static WikiFetcher wf = new WikiFetcher();

    public WikiCrawler(String source, JedisIndex index) {
        this.source = source;
        this.index = index;
        queue.offer(source);
    }

    public int queueSize() {
        return queue.size();
    }

يحتوي هذا الصنف على متغيرات النسخ instance variables التالية:

• source: مُحدّد الموارد الموحد الذي ستبدأ منه.
• index: مفهرِس -من النوع JedisIndex- ينبغي أن تُخزَّن النتائج فيه.
• queue: عبارة عن قائمة من النوع LinkedList. يُفترَض أن تُخزَّن فيها كلُّ محددات الموارد التي عثرت عليها، ولكن لم تُفهرِسها بعد.
• wf: عبارة عن كائن من النوع WikiFetcher. عليك أن تَستخدِمه لقراءة صفحات الإنترنت وتحليلها.

عليك الآن أن تكمل التابع crawl. انظر إلى بصمته:

    public String crawl(boolean testing) throws IOException {}

ينبغي أن تكون قيمة المعامل testing مساويةً للقيمة true إذا كان مستدعيه هو الصنف WikiCrawlerTest، وأن تكون مساويةً للقيمة false في الحالات الأخرى.

عندما تكون قيمة المعامل testing مساويةً للقيمة true، يُفترَض أن يُنفِّذ التابع crawl ما يلي:

• يختار مُحدّدَ موارد موحدًا من الرتل وفقًا لأسلوب "الداخل أولًا، يخرج أولًا" ثم يحذفه منه.
• يقرأ محتويات تلك الصفحة باستخدام التابع WikiFetcher.readWikipedia الذي يعتمد في قراءته للصفحات على نسخٍ مُخزّنةٍ مؤقتًا في المستودع بهدف الاختبار (لكي نتجنَّب أيَّ مشكلات ممكنة في حال تغيّرت النسخُ الموجودةُ في موقع ويكيبيديا).
• يُفهرِس الصفحة بغض النظر عما إذا كانت قد فُهرِسَت من قبل.
• ينبغي أن يجد كل الروابط الداخلية الموجودة في الصفحة ويضيفها إلى الرتل بنفس ترتيب ظهورها. يُقصَد بالروابط الداخلية تلك الروابط التي تشير إلى صفحات أخرى ضمن موقع ويكيبيديا.
• ينبغي أن يعيد مُحدّد الموارد الخاص بالصفحة التي فهرسها.

في المقابل، عندما تكون قيمة المعامل testing مساويةً للقيمة false، يُفترَض له أن يُنفِّذ ما يلي:

• يختار مُحدّد موارد موحدًا من الرتل وفقًا لأسلوب "الداخل أولًا، يخرج أولًا" ثم يحذفه منه.
• إذا كان محدّد الموارد المختار مفهرَسًا بالفعل، لا ينبغي أن يعيد فهرسته، وعليه أن يعيد القيمة null.
• إذا لم يُفهرَس من قبل، فينبغي أن يقرأ محتويات الصفحة باستخدام التابع. WikiFetcher.fetchWikipedia الذي يعتمد في قراءته للصفحات على شبكة الإنترنت.
• ينبغي أن يُفهرِس الصفحة، ويضيف أيَّ روابطَ موجودةٍ فيها إلى الرتل، ويعيد مُحدّد الموارد الخاصَّ بالصفحة التي فهرسها.

يُحمِّل الصنف WikiCrawlerTest رتلًا يحتوي على 200 رابط، ثم يَستدعِي التابع crawl ثلاث مرّات، ويفحص في كلِّ استدعاء القيمةَ المعادة والطولَ الجديد للرتل.

إذا أكملت زاحف الإنترنت الخاص بك بشكل صحيح، فينبغي أن تنجح الاختبارات.

ترجمة -بتصرّف- للفصل Chapter 15: Crawling Wikipedia من كتاب Think Data Structures: Algorithms and Information Retrieval in Java.

اقرأ أيضًا

• المقال التالي: البحث الثنائي Boolean search ودمج نتائج البحث وترتيبها
• المقال السابق: استخدام قاعدة بيانات Redis لحفظ البيانات
• تحليل زمن تشغيل الخرائط المنفذة باستخدام مصفوفة في جافا
• شرح الفروقات بين قواعد بيانات SQL ونظيراتها NoSQL
• كيفية استيراد وتصدير قواعد بيانات MySQL أو MariaDB

سنُكمِل في التمارين القليلة القادمة بناء محرك البحث الذي تحدثنا عنه في مقالة تنفيذ أسلوب البحث بالعمق أولًا تعاوديًّا وتكراريًّا. يتكوَّن أيّ محرك بحثٍ من الوظائف التالية:

• الزحف crawling: ويُنفّذُ من خلال برنامجٍ بإمكانه تحميلُ صفحة إنترنت وتحليلُها واستخراجُ النص وأيِّ روابط إلى صفحاتٍ أخرى.
• الفهرسة indexing: وتنفّذُ من خلال هيكل بيانات data structure بإمكانه البحث عن كلمة والعثور على الصفحات التي تحتوي على تلك الكلمة.
• الاسترجاع retrieval: وهي طريقةٌ لتجميع نتائج المُفهرِس واختيار الصفحات الأكثر صلة بكلمات البحث.

إذا كنت قد أتممت تمرين مقالة استخدام خريطة ومجموعة لبناء مُفهرِّس Indexer، فقد نفَّذت مُفهرسًا بالفعل باستخدام خرائط جافا. سنناقش هذا التمرين هنا وسنُنشِئ نسخةً جديدةً تُخزِّن النتائج في قاعدة بيانات.

وإذا كنت قد أكملت تمرين مقالة تنفيذ أسلوب البحث بالعمق أولًا باستخدام الواجهتين Iterables و Iterators، فقد نفَّذت بالفعل زاحفًا يَتبِع أول رابطٍ يعثرُ عليه. سنُنشِئ في التمرين التالي نسخةً أعمّ تُخزِّن كل رابطٍ تجده في رتل queue، وتتبع تلك الروابط بالترتيب.

في النهاية، ستُكلّف بالعمل على برنامج الاسترجاع.

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

والآن، سنبدأ بالنسخة الجديدة من المُفهرِس.

قاعدة بيانات Redis

تُخزِّن النسخة السابقة من المُفهرِس البيانات في هيكلَيْ بياناتٍ: الأول هو كائنٌ من النوع TermCounter يَربُط كل كلمة بحثٍ بعدد المرات التي ظهرت فيها الكلمة في صفحة إنترنت معينةٍ، والثاني كائنٌ من النوع Index يربُط كلمة البحث بمجموعة الصفحات التي ظهرت فيها.

يُخزَّن هيكلا البيانات في ذاكرة التطبيق، ولذا يتلاشيان بمجرد انتهاء البرنامج. توصف البيانات التي تُخزَّن فقط في ذاكرة التطبيق بأنها "متطايرة volatile"؛ لأنها تزول بمجرد انتهاء البرنامج.

في المقابل، تُوصف البيانات التي تظل موجودةً بعد انتهاء البرنامج الذي أنشأها بأنها "مستمرة persistent". مثال ذلك الملفات المُخزَّنة في نظام الملفات فهي مُستمرة في العموم، وكذلك البيانات المُخزَّنة في قاعدة بيانات أيضًا مستمرة.

يُعدّ تخزين البيانات في ملف واحدة من أبسط طرق حفظ البيانات، فيُمكِننا ببساطة أن نحوِّل هياكل البيانات المُتضمِّنة للبيانات إلى صيغة JSON ثم نكتبها إلى ملف قبل انتهاء البرنامج. عندما نُشغِّل البرنامج مرة أخرى، سنتمكَّن من قراءة الملف وإعادة بناء هياكل البيانات.

ولكن هناك مشكلتان في هذا الحل:

1. عادةً ما تكون عمليتا قراءة هياكل البيانات الضخمة (مثل مفهرس الويب) وكتابتها عمليتين بطيئتين.
2. قد لا تستوعب مساحة ذاكرة برنامج واحد هيكل البيانات بأكمله.
3. إذا انتهى برنامجٌ معينٌ على نحوٍ غير متوقع (نتيجة لانقطاع الكهرباء مثلًا)، فسنفقد جميع التغييرات التي أجريناها على البيانات منذ آخر مرة فتحنا فيها البرنامج.

وهناك طريقة أخرى لحفظ البيانات وهي قواعد البيانات. إذ تُعدّ قواعدُ البيانات البديلَ الأفضلَ، فهي تُوفِّر مساحةَ تخزينٍ مستمرةً، كما أنها قادرةٌ على قراءة جزءٍ من قاعدة البيانات أو كتابته دون الحاجة إلى قراءة قاعدة البيانات أو كتابتها بالكامل.

تتوفَّر الكثير من أنواع نظم إدارة قواعد البيانات DBMS، ويتمتع كلٌّ منها بإمكانيات مختلفة. ويُمكِنك قراءة مقارنة بين أنظمة إدارة قواعد البيانات العلاقية والاطلاع على سلسلة تصميم قواعد البيانات.

تُوفِّر قاعدة بيانات Redis -التي سنَستخدِمها في هذا التمرين- هياكل بيانات مستمرة مشابهةً لهياكل البيانات التي تُوفِّرها جافا، فهي تُوفِّر:

• قائمة سلاسل نصية مشابهة للنوع List.
• جداول مشابهة للنوع Map.
• مجموعات من السلاسل النصية مشابهة للنوع Set.

تُعدّ Redis قاعدة بيانات من نوع زوج مفتاح/قيمة، ويَعني ذلك أن هياكل البيانات (القيم) التي تُخزِّنها تكون مُعرَّفةً بواسطة سلاسل نصية ٍفريدةٍ (مفاتيح). تلعب المفاتيح في قاعدة بيانات Redis نفس الدور الذي تلعبه المراجع references في لغة جافا، أي أنّها تُعرِّف هوية الكائنات. سنرى أمثلةً على ذلك لاحقًا.

خوادم وعملاء Redis

عادةً ما تَعمَل قاعدة بيانات Redis كخدمةٍ عن بعد، فكلمة Redis هي في الحقيقة اختصار لعبارة "خادم قاموس عن بعد REmote DIctionary Server"، ولنتمكن من استخدامها، علينا أن نُشغِّل خادم Redis في مكانٍ ما ثم نَتصِل به عبر عميل Redis. من الممكن إعداد ذلك الخادم بأكثرَ من طريقةٍ، كما يُمكِننا الاختيار من بين العديد من برامج العملاء، وسنَستخدِم في هذا التمرين ما يلي:

1. بدلًا من أن نُثبِّت الخادم ونُشغِّله بأنفسنا، سنَستخدِم خدمةً مثل RedisToGo. تُشغِّل تلك الخدمة قاعدة بيانات Redis على السحابة cloud، وتُقدِّم خطةً مجانيةً بمواردَ تتناسب مع متطلبات هذا التمرين.
2. بالنسبة للعميل، سنَستخدِم Jedis، وهو عبارةٌ عن مكتبة جافا تحتوي على أصنافٍ وتوابعَ يُمكِنها العمل مع قاعدة بيانات Redis.

انظر إلى التعليمات المُفصَّلة التالية لمساعدتك على البدء:

• أنشِئ حسابًا على موقع RedisToGo، واختر الخطة التي تريدها (ربما الخطة المجانية).
• أنشِئ نسخة آلة افتراضية يعمل عليها خادم Redis. إذا نقرت على تبويب "Instances"، ستجد أن النسخة الجديدة مُعرَّفة باسم استضافة ورقم منفذ. كان اسم النسخة الخاصة بنا مثلًا هو dory-10534.
• انقر على اسم النسخة لكي تفتح صفحة الإعدادات، وسجِّل اسم مُحدّد الموارد الموحد URL الموجود أعلى الصفحة. سيكون مشابهًا لما يلي:

redis://redistogo:1234567feedfacebeefa1e1234567@dory.redistogo.com:10534    

يحتوي محدد الموارد الموحد السابق ذكره على اسم الاستضافة الخاص بالخادم dory.redistogo.com، ورقم المنفذ 10534، وكلمة المرور التي سنحتاج إليها للاتصال بالخادم، وهي السلسلة النصية الطويلة المُكوَّنة من أحرف وأعدادٍ في المنتصف. ستحتاج تلك المعلومات في الخطوة التالية.

إنشاء مفهرس يعتمد على Redis

ستجد الملفات التالية الخاصة بالتمرين في مستودع الكتاب:

• JedisMaker.java: يحتوي على بعض الأمثلة على الاتصال بخادم Redis وتشغيل بعض توابع Jedis.
• JedisIndex.java: يحتوي على شيفرةٍ مبدئيةٍ لهذا التمرين.
• JedisIndexTest.java: يحتوي على اختبارات للصنف JedisIndex.
• WikiFetcher.java: يحتوي على شيفرةٍ تقرأ صفحات إنترنت وتُحلِّلها باستخدام مكتبة jsoup. كتبنا تلك الشيفرة في تمارين المقالات المشار إليها بالأعلى.

ستجد أيضًا الملفات التالية التي كتبناها في نفس تلك التمارين:

• Index.java: يُنفِّذ مفهرِسًا باستخدام هياكل بيانات تُوفِّرها جافا.
• TermCounter.java: يُمثِل خريطةً تربُط كلمات البحث بعدد مرات حدوثها.
• WikiNodeIterable.java: يمرّ عبر عقد شجرة DOM الناتجة من مكتبة jsoup.

إذا تمكَّنت من كتابة نسخك الخاصة من تلك الملفات، يُمكِنك استخدامها لهذا التمرين. إذا لم تكن قد أكملت تلك التمارين أو أكملتها ولكنك غير متأكّد مما إذا كانت تَعمَل على النحو الصحيح، يُمكِنك أن تَنسَخ الحلول من مجلد solutions.

والآن، ستكون خطوتك الأولى هي استخدام عميل Jedis للاتصال بخادم Redis الخاص بك. يُوضِّح الصنف RedisMaker.java طريقة القيام بذلك: عليه أولًا أن يقرأ معلومات الخادم من ملفٍّ، ثم يتصل به، ويُسجِل دخوله باستخدام كلمة المرور، وأخيرًا، يُعيد كائنًا من النوع Jedis الذي يُمكِن استخدامه لتنفيذ عمليات Redis.

ستجد الصنف JedisMaker مُعرَّفًا في الملف JedisMaker.java. يَعمَل ذلك الصنف كصنف مساعد حيث يحتوي على التابع الساكن make الذي يُنشِئ كائنًا من النوع Jedis. يُمكِنك أن تَستخدِم ذلك الكائن بعد التصديق عليه للاتصال بقاعدة بيانات Redis الخاصة بك.

يقرأ الصنف JedisMaker بيانات خادم Redis من ملفٍّ اسمه redis_url.txt موجودٍ في المجلد src/resources:

• استخدم مُحرّرَ نصوصٍ لإنشاء وتعديل الملف ThinkDataStructures/code/src/resources/redis_url.txt.
• ضع فيه مُحدّد موارد الخادم الخاص بك. إذا كنت تَستخدِم خدمة RedisToGo، سيكون محدد الموارد مشابهًا لما يلي:

redis://redistogo:1234567feedfacebeefa1e1234567@dory.redistogo.com:10534

لا تضع هذا الملف في مجلدٍ عامٍّ لأنه يحتوي على كلمة مرور خادم Redis. يُمكِنك تجنُّب وقوع ذلك عن طريق الخطأ باستخدام الملف ‎.gitignore الموجود في مستودع الكتاب لمنع وضع الملف فيه.

نفِّذ الأمر ant build لتصريف ملفات الشيفرة والأمر ant JedisMaker لتشغيل المثال التوضيحيّ بالتابع main:

    public static void main(String[] args) {

        Jedis jedis = make();

        // String
        jedis.set("mykey", "myvalue");
        String value = jedis.get("mykey");
        System.out.println("Got value: " + value);

        // Set
        jedis.sadd("myset", "element1", "element2", "element3");
        System.out.println("element2 is member: " + 
                           jedis.sismember("myset", "element2"));

        // List
        jedis.rpush("mylist", "element1", "element2", "element3");
        System.out.println("element at index 1: " + 
                           jedis.lindex("mylist", 1));

        // Hash
        jedis.hset("myhash", "word1", Integer.toString(2));
        jedis.hincrBy("myhash", "word2", 1);
        System.out.println("frequency of word1: " + 
                           jedis.hget("myhash", "word1"));
        System.out.println("frequency of word1: " + 
                            jedis.hget("myhash", "word2"));

        jedis.close();
    }

يَعرِض المثال أنواع البيانات والتوابع التي ستحتاج إليها غالبًا في هذا التمرين. ينبغي أن تحصل على الخرج التالي عند تشغيله:

Got value: myvalue
element2 is member: true
element at index 1: element2
frequency of word1: 2
frequency of word2: 1

سنشرح طريقة عمل تلك الشيفرة في القسم التالي.

أنواع البيانات في قاعدة بيانات Redis

تَعمَل Redis كخريطةٍ تربط مفاتيحَ (سلاسل نصيّة) بقيم. قد تنتمي تلك القيم إلى مجموعة أنواع مختلفة من البيانات. يُعدّ النوع string واحدًا من أبسط الأنواع التي تُوفِّرها قاعدة بيانات Redis. لاحظ أننا سنكتب أنواع بيانات Redis بخطوط مائلة لنُميزها عن أنواع جافا.

سنَستخدِم التابع jedis.set لإضافة سلسلةٍ نصيّةٍ من النوع string إلى قاعدة البيانات. قد تجد ذلك مألوفًا، فهو يشبه التابع Map.put، حيث تُمثِل المعاملات المُمرَّرة المفتاح الجديد وقيمته المقابلة. في المقابل، يُستخدَم التابع jedis.get للبحث عن مفتاحٍ معينٍ والعثور على قيمته. انظر الشيفرة إلى التالية:

        jedis.set("mykey", "myvalue");
        String value = jedis.get("mykey");

كان المفتاح هو "mykey" والقيمة هي "myvalue" في هذا المثال.

تُوفِّر Redis هيكل البيانات set الذي يَعمَل بشكلٍ مشابهٍ للنوع Set<String>‎ في جافا. إذا أردت أن تضيف عنصرًا جديدًا إلى مجموعةٍ من النوع set، اختر مفتاحًا يُحدّد هوية تلك المجموعة، ثم اِستخدِم التابع jedis.sadd كما يلي:

        jedis.sadd("myset", "element1", "element2", "element3");
        boolean flag = jedis.sismember("myset", "element2");

لاحِظ أنه ليس من الضروري إنشاء المجموعة بخطوةٍ منفصلةٍ، حيث تُنشؤها Redis إن لم تكن موجودةً. تُنشِئ Redis في هذا المثال مجموعةً من النوع set اسمها myset تحتوي على ثلاثة عناصر.

يفحص التابع jedis.sismember ما إذا كان عنصر معين موجودًا في مجموعة من النوع set. تَستغرِق عمليتا إضافة العناصر وفحص عضويّتها زمنًا ثابتًا.

تُوفِّر Redis أيضًا هيكل البيانات list الذي يشبه النوع List<String>‎ في جافا. يضيف التابع jedis.rpush العناصر إلى النهاية اليمنى من القائمة، كما يلي:

        jedis.rpush("mylist", "element1", "element2", "element3");
        String element = jedis.lindex("mylist", 1);

مثلما سبق، لا يُعدّ إنشاء هيكل البيانات قبل إضافة العناصر إليه أمرًا ضروريًا. يُنشِئ هذا المثال قائمةً من النوع list اسمها mylist تحتوي على ثلاثة عناصر.

يَستقبِل التابع jedis.lindex فهرسًا هو عبارةٌ عن عددٍ صحيحٍ، ويعيد عنصرَ القائمةِ المشارَ إليه. تَستغرِق عمليتا إضافة العناصر واسترجاعها زمنًا ثابتًا.

أخيرًا، تُوفِّر Redis الهيكل hash الذي يشبه النوع Map<String, String>‎ في جافا. يضيف التابع jedis.hset مُدخَلًا جديدًا إلى الجدول على النحو التالي:

        jedis.hset("myhash", "word1", Integer.toString(2));
        String value = jedis.hget("myhash", "word1");

يُنشِئ هذا المثال جدولًا جديدًا اسمه myhash يحتوي على مدخلٍ واحدٍ يربُط المفتاح word1 بالقيمة "2".

تنتمي المفاتيح والقيم إلى النوع string، ولذلك، إذا أردنا أن نُخزِّن عددًا صحيحًا من النوع Integer، علينا أن نُحوِّله أولًا إلى النوع String قبل أن نَستدعِي التابع hset. وبالمثل، عندما نبحث عن قيمة باستخدام التابع hget، ستكون النتيجة من النوع String، ولذلك، قد نضطرّ إلى تحويلها مرةً أخرى إلى النوع Integer.

قد يكون العمل مع النوع hash في قاعدة بيانات Redis مربكًا نوعًا ما؛ لأننا نَستخدِم مفتاحين، الأول لتحديد الجدول الذي نريده، والثاني لتحديد القيمة التي نريدها من الجدول. في سياق قاعدة بيانات Redis، يُطلَق على المفتاح الثاني اسم "الحقل field"، أي يشير مفتاح مثل myhash إلى جدولٍ معينٍ من النوع hash بينما يشير حقلٌ مثل word1 إلى قيمةٍ ضمن ذلك الجدول.

عادةً ما تكون القيم المُخزَّنة في جداول من النوع hash أعدادًا صحيحة، ولذلك، يوفِّر نظام إدارة قاعدة بيانات Redis بعض التوابع الخاصة التي تعامل القيم وكأنها أعداد مثل التابع hincrby. انظر إلى المثال التالي:

        jedis.hincrBy("myhash", "word2", 1);

يسترجع هذا التابع المفتاح myhash، ويحصل على القيمة الحالية المرتبطة بالحقل word2 (أو على الصفر إذا لم يكن الحقل موجودًا)، ثم يزيدها بمقدار 1، ويكتبها مرةً أخرى في الجدول.

تستغرق عمليات إضافة المُدْخَلات إلى جدول من النوع hash واسترجاعها وزيادتها زمنًا ثابتًا.

تمرين 11

بوصولك إلى هنا، أصبح لديك كل المعلومات الضرورية لإنشاء مُفهرسٍ قادرٍ على تخزين النتائج في قاعدة بيانات Redis.

والآن، نفِّذ الأمر ant JedisIndexTest. ستفشل بعض الاختبارات لأنه ما يزال أمامنا بعض العمل.

يختبر الصنف JedisIndexTest التوابع التالية:

• JedisIndex: يستقبل هذا الباني كائنًا من النوع Jedis كمعامل.
• indexPage: يضيف صفحة إنترنت إلى المفهرس. يَستقبِل سلسلةً نصيّةً من النوع String تُمثِل مُحدّد موارد URL بالإضافة إلى كائن من النوع Elements يحتوي على عناصر الصفحة المطلوب فهرستها.
• getCounts: يستقبل كلمةَ بحثٍ ويعيد خريطةً من النوع Map<String, Integer>‎ تربُط كل محدد مواردَ يحتوي على تلك الكلمة بعدد مرات ظهورها في تلك الصفحة.

يُوضِح المثال التالي طريقة استخدامِ تلك التوابع:

        WikiFetcher wf = new WikiFetcher();
        String url1 = 
            "http://en.wikipedia.org/wiki/Java_(programming_language)";
        Elements paragraphs = wf.readWikipedia(url1);

        Jedis jedis = JedisMaker.make();
        JedisIndex index = new JedisIndex(jedis);
        index.indexPage(url1, paragraphs);
        Map<String, Integer> map = index.getCounts("the");

إذا بحثنا عن url1 في الخريطة الناتجة map، ينبغي أن نحصل على 339، وهو عدد مرات ظهور كلمة "the" في مقالة ويكيبيديا عن لغة جافا (نسخة المقالة التي خزّناها).

إذا حاولنا فهرسة الصفحة مرةً أخرى، ستحُلّ النتائج الجديدة محل النتائج القديمة.

إذا أردت تحويل هياكل البيانات من جافا إلى Redis، فتذكّر أن كل كائنٍ مُخزّنٍ في قاعدة بيانات Redis مُعرَّفٌ بواسطة مفتاحٍ فريدٍ من النوع string. إذا كان لديك نوعان من الكائنات في نفس قاعدة البيانات، فقد ترغب في إضافة كلمةٍ إلى بداية المفاتيح لتمييزها عن بعضها. على سبيل المثال، لدينا النوعان التاليان من الكائنات:

• يُمثِل النوع URLSet مجموعةً من النوع set في قاعدة بيانات Redis. تحتوي تلك المجموعة على محددات الموارد الموحدة URL التي تحتوي على كلمةٍ بحثٍ معينة. يبدأ المفتاح الخاص بكل قيمةٍ من النوع URLSet بكلمة":URLSet"، وبالتالي، لكي نحصل على محددات الموارد الموحدة التي تحتوي على كلمة "the"، علينا أن نسترجع المجموعة التي مفتاحها هو"URLSet:the".
• يُمثِل النوع TermCounter جدولًا من النوع hash في قاعدة بيانات Redis. يربُط هذا الجدول كل كلمة بحث ظهرت في صفحة معيّنة بعدد مرات ظهورها. يبدأ المفتاح الخاصُّ بكل قيمة من النوع TermCounter بكلمة "TermCounter:‎" وينتهي بمحدد الموارد الموحّدِ الخاص بالصفحة التي نبحث فيها.
• يحتوي التنفيذ الخاص بنا على قيمةٍ من النوع URLSet لكل كلمة بحثٍ، وعلى قيمةٍ من النوع TermCounter لكل صفحة مُفهرسَة. وفَّرنا أيضًا التابعين المساعدين urlSetKey و termCounterKey لإنشاء تلك المفاتيح.

المزيد من الاقتراحات

أصبح لديك الآن كل المعلومات الضرورية لحل التمرين، لذا يُمكِنك أن تبدأ الآن إذا أردت، ولكن ما يزال هناك بعض الاقتراحات القليلة التي ننصحك بقراءتها:

• سنوفِّر لك مساعدةً أقلّ في هذا التمرين، ونترك لك حريّة أكبر في اتخاذ بعض القرارات المتعلقة بالتصميم. سيكون عليك تحديدًا أن تُفكِّر بالطريقة التي ستُقسِّم بها المشكلة إلى أجزاءَ صغيرةٍ يُمكِن اختبار كلٍّ منها على حدة. بعد ذلك، ستُجمِّع تلك الأجزاء إلى حلٍّ كاملٍ. إذا حاولت كتابة الحل بالكامل على خطوةٍ واحدةٍ بدون اختبار الأجزاء الأصغر، فقد تستغرِق وقتًا طويلًا جدًا لتنقيح الأخطاء.
• تُمثِّل الاستمرارية واحدةً من تحديات العمل مع البيانات المستمرة، لأن الهياكل المُخزَّنة في قواعد البيانات قد تتغير في كل مرةٍ تُشغِّل فيها البرنامج. فإذا تسبَّبت بخطأٍ في قاعدة البيانات، سيكون عليك إصلاحه أو البدء من جديد. ولكي نُبقِي الأمور تحت السيطرة، وفّرنا لك التوابع deleteURLSets و deleteTermCounters و deleteAllKeys التي تستطيع أن تَستخدِمها لتنظيف قاعدة البيانات والبدء من جديد. يُمكِنك أيضًا استخدام التابع printIndex لطباعة محتويات المُفهرِس.
• في كلّ مرةٍ تستدعي فيها أيًّا من توابع Jedis، فإنه يُرسِل رسالةً إلى الخادم الذي يُنفِّذ بدوره الأمر المطلوب، ثم يردّ برسالة. إذا نفَّذت الكثير من العمليات الصغيرة، فستحتاج إلى وقت طويل لمعالجتها، ولهذا، من الأفضل تجميع متتالية من العمليات ضمن معاملة واحدة من النوع Transaction لتحسين الأداء.

على سبيل المثال، انظر إلى تلك النسخة البسيطة من التابع deleteAllKeys:

    public void deleteAllKeys() {
        Set<String> keys = jedis.keys("*");
        for (String key: keys) {
            jedis.del(key);
        }
    }

في كل مرةٍ تَستدعِي خلالها التابع del، يضطرّ العميل إلى إجراء اتصالٍ مع الخادم وانتظار الرد. إذا كان المُفهرِس يحتوي على بضع صفحاتٍ، فقد يَستغرِق تنفيذ ذلك التابع وقتًا طويلًا. بدلًا من ذلك، يُمكِنك أن تُسرِّع تلك العملية باستخدام كائنٍ من النوع Transaction على النحو التالي:

    public void deleteAllKeys() {
        Set<String> keys = jedis.keys("*");
        Transaction t = jedis.multi();
        for (String key: keys) {
            t.del(key);
        }
        t.exec();
    }

يعيد التابع jedis.multi كائنًا من النوع Transaction. يُوفِّر هذا الكائن جميع التوابع المتاحة في كائنات النوع Jedis. عندما تستدعي أيًّا من تلك التوابع بكائنٍ من النوع Transaction، فإن العميل لا يُنفِّذها تلقائيًا، ولا يتصل مع الخادم، وإنما يُخزِّن تلك العمليات إلى أن تَستدعِي التابع exec، وعندها، يُرسِل جميعَ العملياتِ المُخزَّنة إلى الخادم في نفس الوقت، وهو ما يكون أسرع عادةً.

تلميحات بسيطة بشأن التصميم

الآن وقد أصبح لديك جميع المعلومات المطلوبة، يمكنك البدء في حل التمرين. إذا لم يكن لديك فكرةٌ عن طريقة البدء، يُمكِنك العودة لقراءة المزيد من التلميحات البسيطة.

لا تتابع القراءة قبل أن تُشغِّل شيفرة الاختبار، وتُجرِّب بعض أوامر Redis البسيطة، وتكتب بعض التوابع الموجودة في الملف JedisIndex.java.

إذا لم تتمكّن من متابعة الحل فعلًا، إليك بعض التوابع التي قد ترغب في العمل عليها:

    /**
     * أضف محدد موارد موحدًا إلى المجموعة الخاصة بكلمة
     */
    public void add(String term, TermCounter tc) {}

    /**
     * ابحث عن كلمة وأعد مجموعة مُحدِّدات الموارد الموحدة التي تحتوي عليها
     */
    public Set<String> getURLs(String term) {}

    /**
     * أعد عدد مرات ظهور كلمة معينة بمحدد موارد موحد
     */
    public Integer getCount(String url, String term) {}

    /**
     * ‫أضف محتويات كائن من النوع `TermCounter` إلى قاعدة بيانات Redis
     */
    public List<Object> pushTermCounterToRedis(TermCounter tc) {}

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

اكتب بعض الاختبارات لكل تابعٍ منها أولًا، فبمعرفة الطريقة التي ينبغي بها أن تختبر تابعًا معينًا، عادةً ما تتكوَّن لديك فكرةٌ عن طريقة كتابته.

ترجمة -بتصرّف- للفصل Chapter 14: Persistence من كتاب Think Data Structures: Algorithms and Information Retrieval in Java.

اقرأ أيضًا

• المقال التالي: فهرسة الصفحات وتحليل زمن تشغيلها باستخدام قاعدة بيانات Redis
• المقال السابق: استخدام أشجار البحث الثنائية والأشجار المتزنة balanced trees لتنفيذ الخرائط
• تحليل نظام الملفات لإدارة البيانات وتخزينها واختلافه عن نظام قاعدة البيانات
• شرح الفروقات بين قواعد بيانات SQL ونظيراتها NoSQL
• كيفية استيراد وتصدير قواعد بيانات MySQL أو MariaDB

إنّ السجلّات logs أمر ضروري لحل مشاكل تثبيت Redis، وقد تتساءل عن مكان تواجد هذه السجلّات أو عن المكان الذي يقوم Redis بتخزين السجلّات فيه على نظام Ubuntu.

عند تثبيت Redis بالطريقة الافتراضية باستخدام apt-get على Ubuntu 14.04 فسيقوم Redis بإنشاء سجلّاته في المسار var/log/redis/redis-server.log/.

لاستعراض آخر 10 أسطر في سجلّات redis، نقوم بتنفيذ الأمر التالي:

$ sudo tail /var/log/redis/redis-server.log

لاحظ في الأمر السابق استخدامنا لـ sudo نظرًا لأننا نحتاج لصلاحيات أعلى لنتمكن من قراءة سجلّات redis.

أما في حال تثبيت Redis من ملفّات الشيفرة المصدرية على Ubuntu 14.04، فسيقوم بتخزين السجلّات في المسار var/log/redis_6379.log/.

ولاستعراض آخر 10 أسطر نستخدم الأمر:

$ sudo tail /var/log/redis_6379.log

التحقق من السجلات المؤرشفة

يقوم Redis بأرشفة ملفّات السجلّات القديمة، ولاستعراض قائمة الملفّات المتوفرة ننفذ الأمر:

$ ls /var/log/redis

فسيظهر الخرج بما يشبه التالي:

redis-server.log redis-server.log.1.gz

ولاستعراض آخر 10 أسطر من سجل مؤرشف نحتاج أولًا أن نقوم بفك ضغطه، ونستخدم gunzip لفك ضغط الملفات من نوع gz، كما في الأمر التالي:

$ sudo gunzip /var/log/redis/redis-server.log.1.gz

انتبه: يقوم gunzip بفك ضغط ملفات gz وحذف الملف الأساسي المضغوط، لذا إن كنت تريد المحافظة على الأرشيف المضغوط توفيرًا للمساحة واستعراض محتويات الملف المضغوط بشكل مؤقت فقم بنسخه إلى المسار المؤقت tmp/ وقم بفك ضغطه هناك.

ومن ثم ننفذ الأمر tail مع الملف الذي نحصل عليه:

$ sudo tail /var/log/redis/redis-server.log.1

البحث عن ملفات السجلات باستخدام أمر find

إن لم تكن ملفّات السجلّات في المسارات المذكورة السابقة، فمن الممكن تنفيذ عملية بحث واسعة باستخدام الأمر find في المسار var/logs/ على الشكل التالي:

$ find /var/log/* -name *redis*

أو البحث في كامل النظام.

قد تأخذ عملية البحث بهذا الشكل بعض الوقت إن كنت تملك الكثير من الملفّات، وقد تظهر لك بعض التحذيرات حول عدم كفاية الصلاحيات للبحث في بعض المسارات، وهذا أمر طبيعي، بالرغم من أنّنا نتجنب أسوأ مسارين للبحث فيهما وهما proc/ و sys/ باستعمال المعامل prune-. سيظهر تنفيذ الأمر التالي جميع الملفّات التي تحوي على كلمة redis في اسمه، بما في ذلك ملفات التثبيت:

$ find / -path /sys -prune -o -path /proc -prune -o -name *redis*

تحديد مسار تخزين السجلات في ملف إعدادات Redis

نستطيع تغيير مسار تخزين ملفات السجلّات وذلك بتغيير المسار في ملف الإعدادات redis.conf، ويتواجد الملف غالبًا في المسار etc/redis/redis.conf/

نقوم بفتح الملف بمحرر نصوص مثل nano أو أي محرر آخر تفضّله:

$ sudo nano /etc/redis/redis.conf

ونبحث عن السطر الذي يبدأ بـ logfile ونقوم بتغيير المسار الذي يظهر فيه إلى المسار الجديد، كما بالإمكان تغيير اسم ملف السجل الأساسي:

logfile /var/log/redis/redis-server.log

التحقق من سجلات systemd باستخدام journalctl في Ubuntu 15.04 والإصدارات الأحدث منه

قد نحتاج أن نتحقق من سجلّات Redis التي يقوم بالتقاطها سجل النظام systemd (يستخدم نظام Ubuntu 15.04 والأحدث منه سجل النظام systemd، بينما يستخدم Ubuntu 14.04 سجّلات Upstart بشكل افتراضي).

الخلاصة

لتتعلّم المزيد حول إعدادات Redis، يرجى قراءة هذا المقال حول إعداد عنقود Redis cluster.

ترجمة -وبتصرّف- للمقال How To Find Redis Logs on Ubuntu لصاحبته Sharon Campbell.

سنتطرق في هذا الدّرس إلى كيفية تطبيق حماية أساسيّة لخادوم Redis.

على الرغم من هذا، عليك تذكر بأن Redis قد صُمّم أساسا للاستخدام من طرف مستخدمين موثوقين على بيئة موثوقة، بدون أي مميزات أمنيّة خاصة به. لفهم هذه النّقطة أكثر إليك اقتباسا من الموقع الرسمي لـredis:

اقتباس

"Redis مُصمّم للوصول إليه من عملاء موثوقين داخل بيئة موثوقة. ما يعني أن توفير الوصول إلى خادوم Redis الخاص بك مباشرة على الإنترنت، أو من بيئة يُمكن لمستخدمين غير موثوقين أن يصلوا مباشرة إلى منفذ TCP الخاص بـ Redis أو إلى مقبس UNIX ليست فكرة جيّدة."

بشكل عام، Redis ليس مُحسّنا لحماية قصوى بل لأداء عالي وبساطة فائقة.

الأداء والبساطة بلا حماية بمثابة وصفة لكارثة. حتى مميّزات الحماية القليلة لدى Redis ليست ممتازة، وتشمل كلمة مرور بسيطة غير مُشفّرة، إعادة تسميّة الأوامر وتعطيلها. وتفتقر إلى نظام حقيقي للتحكم بالولوج.

على الرغم من هذا، فإن ضبط هذه الخصائص الأمنيّة يبقى خطوة كبيرة إلى الأمام وأفضل من ترك قاعدة بياناتك بدون حماية.

ستقرأ في هذا الدّرس كيفيّة ضبط الخصائص الأمنيّة القليلة التي يمتلكها Redis، وبعض الخصائص الأمنية الأخرى للنظام ما سيزيد من نسبة الحماية لخادوم Redis مُستقل على Ubuntu 14.04.

ننوّه إلى أن هذا الدرس لا يتحدث عن حالات وجود كل من خادوم Redis وتطبيقات العملاء على استضافات مختلفة أو مراكز بيانات مختلفة. أو الحالات التي يجب على الاتصال بـ Redis أن يقطع شبكات غير آمنة أو غير موثوقة تتطلب نوعا مختلفا من الإعداد، مثل ضبط SSL proxy أو VPN بين خواديم Redis ، إضافة إلى الخطوات المذكورة هنا.

المتطلبات

ستحتاج في هذا الدّرس:

• خادوم Ubuntu مع مستخدم sudo مُضَاف، انظر درس الإعداد الابتدائي لخادوم أوبنتو 14.04
• جدار ناري iptables معدّ باستخدام الدرس كيف تنفذ نموذجا للجدار الناري باستعمال Iptables إلى غاية خطوة "تحديث nameservers" (إذا لم تقم بإعداد جزء الخادوم nameserver فالـAPT لن يعمل).
• Redis مُثبت وقيد التنفيذ باستعمال الخطوات في الموضحة في الدرس كيفية تنصيب واستخدام Redis على أوبنتو.

الخطوة الأولى، التأكد من أن Redis قيد التشغيل

أولاً ادخل إلى الخادوم باستعمال SSH:

ssh username@server-ip-address

• username: اسم المستخدم
• server-ip-address: عنوان IP الخاص بالخادوم

للتأكد من أنّ Redis قيد التنفيذ، استعمل سطر الأوامر الخاص ب Redis .يُستعمل الأمر redis-cli للوصول إلى سطر أوامر Redis.

redis-cli

إذا سبق وأن أعددت كلمة مرور لـ Redis، فيجب عليك الاستيثاق بالأمر auth بعد الاتّصال:

auth كلمة_المرور

المخرج سيكون كلمة OK

اختبر خادوم قاعدة البيانات:

ping

الرّد:

PONG

اُخرج:

quit

الخطوة الثانية، حماية الخادوم بـاستخدام Iptables

إذا اتّبعت المُتطلّبات من أجل ضبط Iptables، فلك كامل الحريّة في تخطّي هذه الخطوة، أو يُمكنك القيام بذلك الآن.

Redis مجرّد تطبيق يُنفّذ على خادومك، ولأنه لا يملك أي خصائص أمنيّة خاصة، فإنّ أول خطوة لحمايته حقيقة تكمن في حماية الخادوم الذي يُشغل منه.

في حالة خادوم موجّه للعامة كخادومك Ubuntu 14.04، فإن ضبط جدار ناريّ كما هو مبيّن في درس Iptables يُعتبر الخطوة الأولى لذلك. اتّبع ذلك الرّابط واضبط جدارا ناريّا الآن.

إذا طبّقت أحكام الجدار النّاري باستعمال ذلك الدّرس، فلن تحتاج لإضافة قاعدة أخرى لـ Redis،

افتراضيّاً، إن أي مرور traffic يُمنَع إلّا عند السّماح له صراحةً. وبما أن خادوم Redis افتراضيّا يستمع على واجهة الاسترجاع (loopback (127.0.0.1 أو localhost، فلا يجب القلق حول المرور عبر المنفذ الافتراضي.

إذا كنت تحتاج للسّماح لعنوان IP للوصول خصّيصا لـ Redis، يُمكنك التحقق من العنوان الذي يستمع منه Redis، وعلى أي منفذ باستخدام أمر grep لمُخرجات الأمر netstat. العمود الرّابع 127.0.0.1:6379 يطلعنا على عنوان IP والمنفذ المرتبطين بـ Redis:

sudo netstat -plunt | grep -i redis

المخرجات:

tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8562/redis-server 1

تأكّد من أن هذا العنوان مسموح له في الجدار النّاري. للمزيد من المعلومات عن كيفيّة إضافة الأحكام، اطّلع رجاء على درس أساسيّات Iptables.

الخطوة الثالثة، الربط إلى المضيف المحلي localhost

افتراضيًّا، يُمكن الوصول إلى خادوم Redis من المضيف المحليّ، على أي حال، إذا اتّبعت درس ضبط Redis على خادوم متبوع/سيّد فقد حدّثت ملفّ الإعدادات للسّماح للاتّصالات من أي مكان. وهذا ليس آمنا كالربط إلى المُضيف المحليّ.

افتح ملفّ إعدادات Redis للتّعديل:

sudo nano /etc/redis/redis.conf

ابحث عن هذا السّطر وتأكّد من أنه ليس على شكل تعليق (احذف الرّمز # إذا كان موجودا):

bind 127.0.0.1

سنستمرّ في استعمال هذا الملفّ، لذلك أبقه مفتوحا الآن.

الخطوة الرابعة، ضبط كلمة مرور لـ Redis

إذا ثبتت Redis باتّباع درس كيف تضبط خواديم Redis متعددة على أوبنتو 14.04 فيجب عليك أن تكون قد ضبطت كلمة مرور مُسبقا، يُمكنك أن تضع كلمة مرور أكثر أمانا باتّباع هذا القسم الآن، وهذه الخطوات تعرض كيفية وضع كلمة مرور لخادوم قاعدة البيانات.

ضبط كلمة مرور لـ Redis يفعّل إحدى ميزتي الحماية المُضمّنة في Redis، وهو الأمر auth، الذي يطلُب من العملاء الاستيثاق للوصول إلى قاعدة البيانات. تُضبَطُ كلمة المرور مُباشرة في ملف الإعدادات etc/redis/redis.conf/ الذي يجب أن تكون قد فتحته منذ الخطوة الماضيّة.

اذهب عن قسم SECURITY وابحث عن سطر مُعلّق بالرمز # كالتّالي:

# requirepass foobared

أزل التّعليق عن السّطر بحذف الرمز #، وغيّر foobared إلى كلمة مرور قويّة وطويلة.

عوضاً عن الإتيان بكلمة مرور من عندك، يمكنك استعمال أداة مثل apg و pwgen لتوليد واحدة. إذا لم تكن ترغب بتثبيت أداة فقط لتوليد كلمة مرور، يُمكنك استخدام السطر التّالي. لتوليد كلمة مرور مُختلفة عن هذا المثال غير القيمة بداخل علامتي التنصيص:

echo "hsoub-academy" | sha256sum

المُخرج سيبدو كالتّالي:

e118c2b8fa805fbd0a6af458ab7df9fea14881b87c2e793b4a2192cda30bf8d5

لكنّ كلمة المرور المولّدة لن تكون منطوقة، وهي قويّة وطويلة وهو تماما المطلوب لحماية Redis. بعد نسخ ولصق مُخرج هذا الأمر كقيمة جديدة لـ requirepass، يجب أن تكون كالتّالي:

requirepass 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d

إذا كنت تُفضّلُ كلمة مرور أقصر، استخدم مُخرج الأمر التالي عوضا عنها. غيّر القيمة بين علامتي التنصيص لكي لا تولّد نفس كلمة المرور:

echo "hsoub-academy" | sha1sum

المخرج سيكون أقصر هذه المرّة:

773a12cfe8616ff740258f8843c567f32227ac0f

بعد ضبط كلمة المرور، احفظ الملفّ وأعد تشغيل Redis :

sudo service redis-server restart

لاختبار عمل كلمة المرور، حاول الوصول إلى سطر أوامر Redis :

redis-cli

السطر التالي يعرض سلسلة من الأوامر المُستعملة لاختبار ما إذا كانت كلمة المرور تعمل أو لا، الأمر الأول يُحاول إعطاء قيمة لمفتاح قبل القيام بالاستيثاق:

set key1 10

الأمر لن يعمل، لذلك فإنك سترى خطأ في المخرجات:

(error) NOAUTH Authentication required.

الأمر الثاني يقوم بالاستيثاق بكلمة المرور التي وضعناها في ملفّ إعدادات Redis.

auth your_redis_password

سيُوافق Redis في الحال:

OK

بعد هذا، تنجح إعادة تنفيذ الأمر السّابق.

set key1 10

المُخرج:

OK

الأمر get key1 يطلب من Redis قيمة المفتاح الجديد:

get key1

المُخرج:

“10”

الأمر الأخير يقوم بإنهاء سطر الأوامر redis-cli. ويمكنك أيضاً استخدام exit:

quit

تالياّ، سننظر إلى إعادة تسميّة أوامر Redis.

الخطوة الخامسة، إعادة تسمية الأوامر الخطرة

الخاصيّة الأمنيّة الأخرى المبنيّة داخل Redis تُخوّل لك إعادة تسميّة أو تعطيل أوامر معيّنة والتّي تُعتبر أوامر خطيرة.

عند تشغيل مستخدمين غير مُخولين لأوامر معينّة فقد تُستخدم هذه الأوامر لإعادة ضبط، أو تدمير أو حذف بياناتك. ومثل كلمة مرور الاستيثاق،فإن إعادة تسمية الأوامر أو تعطيلها تتم في نفس قسم SECURITY من الملفّ etc/redis/redis.conf/.

بعض الأوامر المعروف أنها خطيرة هي:

FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME و DEBUG

وهذه القائمة ليست شاملة، لكنّ إعادة تسميّتها أو تعطيلها كلّها يُعتبر نقطة بداية جيّدة.

تعطيل أو إعادة تسميّة أمر يعتمد على مدى استعمالك للأمر، فمثلاً إذا كنت تعلم أنّك لن تستعمل أبدا أمرا يُمكن أن يُستَغلّ سلبيّاً، فمن المستحسن أن تُعطّله، عدا ذلك فمن الأفضل إعادة التّسميّة.

لتشغيل أو تعطيل أمر ما، افتح ملفّ الإعدادات للتحرير مرة أخرى:

sudo nano /etc/redis/redis.conf

هذه بعض الأمثلة فقط. ويجب عليك أن تعيد تسميّة أو تعطّل الأوامر بما يُناسبك. يُمكنك التحقق من الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands.

لتعطيل أو إيقاف أمر ما، فقط أعد تسميّتها إلى قيمة فارغة كما هو مبيّن أسفله:

# It is also possible to completely kill a command by renaming it into

# an empty string:

#

rename-command FLUSHDB ""

rename-command FLUSHALL ""

rename-command DEBUG ""

وعند إعادة تسميّة أمر ما، عيّن اسما آخر كقيمة، كما في الأمثلة أسفله. الأوامر المعاد تسميّتها يجب أن تكون صعبة التخمين، وفي نفس الوقت سهلة التذكر بالنسبة لك.ولا تجعلها صعبة عليك.

rename-command CONFIG ""

rename-command SHUTDOWN SHUTDOWN_MENOT

rename-command CONFIG ASC12_CONFIG

بعد إعادة التّسميّة، طبّق التعديلات بإعادة تشغيل Redis:

sudo service redis-server restart

لاختبار الأمر الجديد، ادخل إلى سطر أوامر Redis:

redis-cli

بعد ذلك، على افتراض بأنّك قمت بإعادة تسميّة الأمر CONFIG إلى ASC12_CONFIG، المُخرج التّالي يوضح كيفيّة التأكد من أنّ الأمر الجديد يعمل.

بعد الاستيثاق:

auth your_redis_password

المُخرج:

OK

يجب أن تكون مُحاولة استخدام الأمر config باسمه الأصلي فاشلة، لأنّنا بالطبع قمنا بإعادة تسميّتها:

config get requirepass

المُخرج":

(error) ERR unknown command 'config'

مناداة الأمر باسمه الجديد سيعمل (وهو غير حسّاس لحالة الأحرف):

asc12_config get requirepass

المُخرج:

1) "requirepass"
2) "your_redis_password"

أخيرا، يمكنك الخروج من redis-cli:

exit

ملاحظة: إذا كنت تستخدم مسبقا سطر الأوامر Redis ثم أعدت تشغيل Redis، سيتوجب عليك إعادة الاستيثاق. إن لم تقوم بذلك، ستحصل على هذا الخطأ عند كتابة أمر ما:

NOAUTH Authentication required.

على الرغم من إعادة تسميّتك للأوامر، فهناك جملة تحذيريّة في آخر قسم SECURITY على ملفّ etc/redis/redis.conf/ تقول:

اقتباس

يرجى ملاحظة أن تغيير أسماء الأوامر الداخلة في ملفّ AOF أو المُحالة إلى التّوابع (Slaves) قد تُسبّب المشاكل.

هذا يعني أنّه إذا لم يكن الأمر المعاد تسميّته داخل ملفّ AOF، أو إذا كان موجودا لكنّ ملفّ AOF لم يُحَلْ إلى التّوابع، فلا يجب أن يكون هناك أي مُشكلة.

لذلك تذكّر عند محاولة تغيير أسماء الأوامر، أفضل وقت لإعادة تسميّة أمر هو عند عدم استخدام AOF، أو مباشرة بعد التثبيت أي قبل نشر التطبيق المُستعمِل لـ Redis.

عندما تستخدم AOF وعند التّعامل مع نظام تابع-متبوع، ضع في بالك هذه الإجابة من صفحة المسائل في المشروع على Github. الاقتباس التّالي هو جواب على سؤال الكاتب:

اقتباس

تُسجّل الأوامر إلى الـ AOF وتنسخ إلى التّابع بطريقة الإرسال ذاتها، لذلك إذا حاولت رد AOF على نموذج لا يمتلك نفس أسماء الأوامر، فقد تواجه تناقضات لأن الأمر لا يُمكن تنفيذه (الأمر نفسه يقع بالنسبة للتّوابع).

لذلك فإن أفضل طريقة للتعامل مع إعادة التسمية في حالات كهذه هي أن تتأكّد من أنّ إعادة تسميّة الأوامر مطبّقة في جميع الخوادم في أنظمة تابع-متبوع.

الخطوة السادسة، ضبط مجلد البيانات وصلاحيات المستخدم للملفات

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

يُمكنك التحقق من هذا باستخدام أداة grep مع الأمر ls لرؤية معلومات عن المُجلّد الأب لمجلّد بيانات Redis. الأمر والمُخرجات أسفله.

ls -l /var/lib | grep redis

المُخرج:

drwxr-xr-x 2 redis   redis   4096 Aug  6 09:32 redis

يُمكنك ملاحظة بأن مجلّد بيانات Redis مملوك من طرف المُستخدم Redis، مع وصول ثانوي للمجموعة redis. وهذا أمر جيّد.

الأمر السيئ هو صلاحيّات الوصول إلى المُجلّد، أي 755. للتأكد من أن المُستخدم redis هو فقط من يمتلك حقّ الوصول إلى المجلد ومُحتوياته، غيّر الصلاحية إلى 700:

sudo chmod 700 /var/lib/redis

الصلاحيّة الأخرى التّي عليك تغييرها هي الخاصّة بملفّ إعدادات Redis. يمتلك افتراضيّا صلاحيّة 644 ومملوك للمُستخدم الجذر root، مع مالك ثانوي يتمثّل في مجموعة الجذر root group:

ls -l /etc/redis/redis.conf

المُخرج:

-rw-r--r-- 1 root root 30176 Jan 14 2014 /etc/redis/redis.conf

هذه الصّلاحيّة (644) تعني مقروء من الكل، والتي تعتبر فكرة سيّئة لأن ذلك الملف يحتوي على كلمة المرور غير المُشفرة التّي وضعناها في الخطوة الرّابعة.

نحتاج إلى تغيير المالك والصّلاحيّات. يجبُ أن تكون مملوكة للمُستخدم redis مع مجموعة الجذر كمالك ثانوي، لفعل ذلك، شغّل الأمر التّالي:

sudo chown redis:root /etc/redis/redis.conf

بعد ذلك غيّر المالك لكي يتمكّن مالك الملفّ فقط من قراءته أو/و الكتابة عليه:

sudo chmod 600 /etc/redis/redis.conf

يُمكنك التحقّق من المالك الجديد والصّلاحيّات باستخدام الأمر:

ls -l /etc/redis/redis.conf

المُخرج:

total 40

-rw------- 1 redis root 29716 Sep 22 18:32 /etc/redis/redis.conf

في الأخير، أعد تشغيل Redis:

sudo service redis-server restart

خاتمة

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

للتّقدّم بحماية خادومك إلى المستوى التّالي، فعليك ضبط نظام كشف تطفّل مثل OSSEC.

إذا كنت تريد حماية تواصل Redis عبر شبكات غير آمنة فعليك توظيف SSL proxy، كما هو منصوح به من مطوّري Redis على دليل حمايةRedis الرسمي. وضبط SSL proxy لحماية تواصل Redis فهو موضوع آخر.

لم نتطرّق إلى قائمة شاملة من أوامر Redis بقسم إعادة التّسميّة، لكنّك تستطيع إلقاء نظرة على مجموعة الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands.

ترجمة -بتصرّف- للمقال How To Secure Your Redis Installation on Ubuntu 14.04 لصاحبه finid.

Redis عبارة عن نظام تخزين مؤقّت cache بنمط مفتاح-قيمة key-value مفتوح المصدر.

إن كنت ترغب في استخدام Redis على بيئة الإنتاج الخاصة بك، فإن نسخ بياناتك على خادومين على الأقل يُعتبر من بين أفضل الممارسات (best practices)، تتيح الوفرة الاسترداد في حالة فشل البيئة، ما يُعتبر مهمّا عند نمو قاعدة مستخدمي تطبيقك.

بنهاية هذا الدرس، سنضبط خادومي Redis كالتالي:

• خادوم Redis للمتبوع/السيد (master server)
• خادوم Redis للتّابع (slave server)

سنشرح كذلك كيفيّة الانتقال إلى خادوم التّابع وضبطه كسيّدِِ مؤقّت.

لك كامل الحريّة في ضبط أكثر من خادوم واحد خاص بالتابع.

هذا الدرس يركز على ضبط عنقود تابع ومتبوع خاص بـredis، لتعلم المزيد عن Redis بشكل عام واستخدامه الأساسي كقاعدة بيانات، ألق نظرة على هذا الدرس.

المتطلبات

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

سنعتمد على:

• نظام أوبنتو Ubuntu 14.04 LTS.
• خادومين، بأي حجم تريد، واحد متبوع وآخر أو أكثر للتّوابع.
• ادخل إلى خواديمك عبر SSH مع مستخدم غير جدري مع صلاحيّات sudo كما هو مبيّن في الإعداد الابتدائي لخادوم أوبنتو 14.04 .

الخطوة الأولى: تثبيت Redis

سنبدأ مع الخادوم الذي سيستضيف المتبوع/السّيّد، وأول خطوة هي تثبيت Redis. أولا نحتاج إلى إضافة مستودع Redis الخاص بـ Chris Lea (كما جرت عليه العادة، توخ الحذر عند إضافة مستودعات طرف ثالث، نستخدم هذا المستودع لأن صاحبه حسنُ السمعة):

sudo add-apt-repository ppa:chris-lea/redis-server

اضغط ENTER لقبول المستودع.

شغل الأمر التالي لتحديث الحزم:

sudo apt-get update

ثبت خادوم Redis:

sudo apt-get update

تأكد أنّ Redis مُشغل وقيد التنفيذ:

redis-benchmark -q -n 1000 -c 10 -P 5

الأمر أعلاه يخبر بأننا نريد تشغيل الأمر redis-benchmark في وضع صامت، مع 1000 طلبات إجماليّة، 10 اتصالات موازية، و 5 طلبات أنابيب. للمزيد من المعلومات عن هذا الأمر، شغّل الأمر redis-benchmark –help على الطرفيّة لتظهر لك معلومات وأمثلة حول الأمر.

بعد انتهاء العمليّة، يجب أن ترى مُخرجات تبدو كالتالي:

PING_INLINE: 166666.67 requests per second
PING_BULK: 249999.98 requests per second
SET: 249999.98 requests per second
GET: 499999.97 requests per second
INCR: 333333.34 requests per second
LPUSH: 499999.97 requests per second
LPOP: 499999.97 requests per second
SADD: 499999.97 requests per second
SPOP: 499999.97 requests per second
LPUSH (needed to benchmark LRANGE): 499999.97 requests per second
LRANGE_100 (first 100 elements): 111111.12 requests per second
LRANGE_300 (first 300 elements): 27777.78 requests per second
LRANGE_500 (first 450 elements): 8333.33 requests per second
LRANGE_600 (first 600 elements): 6369.43 requests per second
MSET (10 keys): 142857.14 requests per second

الخطوة الثانية: ضبط Redis المتبوع

الآن بما أن Redis قيد التنفيذ على العنقود المتكون من الخادومين، يجب علينا تعديل ملفات الإعدادات. كما سنرى، هناك اختلافات طفيفة بين ضبط الخادوم المتبوع والتابع.

لنبدأ أولا مع المتبوع master.

افتح الملف etc/redis/redis.conf/ باستخدام محرر النصوص المُفضّل لديك:

sudo nano /etc/redis/redis.conf

وعدّل الأسطر التّالية:

ضع قيمة معقولة لمؤقّت الإبقاء على قيد الحياة KeepAlive للـTCP:

tcp-keepalive 60

اجعل الخادوم متاحا للجميع على الويب بجعل هذا السّطر كتعليق (أو بحذفه):

#bind 127.0.0.1

بحكم طبيعة Redis وسرعاتها العاليّة قد ينفذ مهاجم هجوم القوة الغاشمة Brute force على كلمة المرور. لذلك ننصح إزالة تعليق سطر requirepass وإضافة كلمة مرور معقّدة (أو من الأفضل أن تكون جملة مرور معقدة):

requirepass your_redis_master_password

على حسب سيناريو استخدامك، قد ترغب في تعديل السّطر التالي أو لا. لغرض هذا الدرس ، نفترض أن حذف أي مفتاح key deletion ممنوع. قم بإزالة التعليق عن هذا السّطر واضبطه كالتالي:

maxmemory-policy noeviction

أخيرا، سنقوم بالتعديلات التاليّة، وهي مطلوبة للنسخ الاحتياطي للبيانات. أزل التعليق/أو اضبط هذه الأسطر كالتالي:

appendonly yes
appendfilename redis-staging-ao.aof

احفظ التغييرات.

أعد تشغيل خدمة Redis لإعادة تحميل تعديلات الضبط التي قمنا بها.

sudo service redis-server restart

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

الآن وبعد أن جهزنا خادوم المتبوع أو السيّد، لننتقل إلى خادوم التابع.

الخطوة الثالثة: إعداد Redis التابع

نحتاج للقيام ببعض التعديلات التي ستسمح لخادوم التابع بالاتّصال مع المتبوع:

افتح الملف etc/redis/redis.conf/ بمحررك المُفضل:

sudo nano /etc/redis/redis.conf

عدّل الأسطر التالية، بعض الإعدادات ستكون تماما مثل الإعدادات الخاصة بالمتبوع.

اجعل الخادوم متاحا للجميع على الويب بتحويل هذا السطر إلى تعليق (عبر إضافة # إلى بدايته):

#bind 127.0.0.1

يحتاج التابع كذلك إلى كلمة مرور لنستطيع إعطاء الأوامر له (مثل INFO). أزل التعليق عن هذا السطر وضع كلمة سر للخادوم:

requirepass your_redis_slave_password

أزل التعليق عن هذا السطر وضع عنوان IP الخاص بالمتبوع، متبوعا برقم المنفذ المضبوط على الخادوم. افتراضيّا يكون الرقم 6379 هو رقم المنفذ:

SLAVEOF your_redis_master_ip 6379

تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع.

احفظ الآن هذه التغييرات، واخرج من الملف. ومن ثم، أعد تشغيل الخدمة كما فعلنا مع خادوم المتبوع:

sudo service redis-server restart

هذا الأمر سيعيد ضبط Redis وسيحمل الملفات التي عدّلناها.

اتصل بـredis:

redis-cli -h 127.0.0.1 -p 6379

استوثق بكلمة المرور الخاصة بالتابع:

AUTH your_redis_slave_password

لقد شغّلنا الآن عنقود Redis يعمل كتابع ومتبوع، مع ضبط كل من الخادومين بشكل صحيح.

الخطوة الرابعة: تحقق من نسخ التابع-المتبوع

سيسمح لنا اختبار هذا التّنصيب فهم كيفية تصرف خوادم Redis بشكل أفضل، عندما نرغب في بداية برمجة الحماية من الفشل. ما سنفعله الآن هو التحقق من أن الإعدادات تعمل بشكل صحيح، وأن المتبوع يتواصل مع التابع بشكل صحيح.

أولا، نتصل بـredis عبر الطرفيّة، على خادوم المتبوع:

اتّصل أولا بالنموذج المحليّ، مع استعمال المنفذ الافتراضي 6379. إذا كنت قد غيّرت المنفذ، فغير الأمر بما يناسب:

redis-cli -h 127.0.0.1 -p 6379

الآن، استوثق مع Redis باستعمال كلمة المرور التي وضعتها عند ضبط المتبوع:

AUTH your_redis_master_password

يجب عليك أن تحصل على OK كمُخرج. الآن، كل ما عليك فعله هو تنفيذ الأمر:

INFO

سترى كلّ ما تحتاج معرفته عن خادوم المتبوع. ما يهمنا هو القسم Replication# والذي يجب أن تبدو كالمخرجات التاليّة:

. . .

# Replication
role:master
connected_slaves:1
slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406

. . .

لاحظ سطر connected_slaves:1، الذي يخبرنا بأن نموذج التابع يتواصل مع الخادوم المتبوع. كما يُمكنك ملاحظة أنّنا حصلنا على عنوان IP الخاص بالتابع، وكذلك المنفذ، الحالة، ومعلومات أخرى.

الآن لنلق نظرة على قسم Replication# في الخادوم الخاص بالتابع، العمليّة نفسها التي قمنا بها مع المتبوع، ادخل إلى Redis، طبق الأمر INFO، وانظر إلى المُخرجات:

. . .

# Replication
role:slave
master_host:111.111.111.111
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:1401
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

يُمكننا ملاحظة أن هذا الخادوم يقوم بدور التابع، وأنه يتواصل مع خادوم Redis المتبوع، ولا يملك أي توابع خاصة به.

الخطوة الخامسة: التبديل إلى التابع

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

على خادوم التابع، يجب أن نتصل مع نموذج Redis:

redis-cli -h 127.0.0.1 -p 6379

الآن قم بالاستيثاق مع Redis باستخدام كلمة المرور التي استخدمتها عند ضبط التابع.

AUTH your_redis_slave_password

قم بإنهاء دور التابع:

SLAVEOF NO ONE

يجب الحصول على OK كمُخرج. الآن، نفذ الأمر:

INFO

قسم Replication# في الرد يجب أن يبدو كالمخرجات التاليّة:

. . .

# Replication
role:master
connected_slaves:0
master_repl_offset:1737
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

كما هو متوقع، فقد تحول التابع إلى متبوع، وهو الآن جاهز لقبول اتّصالات من خوادم أخرى (إذا كانت موجودة). يُمكننا استعماله كمخزن نسخ احتيّاطي مؤقّت أثناء إصلاح الأخطاء في المتبوع الأصلي.

إذا كنت تمتلك عدة توابع مُعتمدة على المتبوع الرئيسي، فسيتوجب عليك توجيههم إلى المتبوع الجديد.

يُمكن القيّام بذلك بسهولة، بالخطوات التاليّة التي يجب تطبيقها في حال كُشِف عن أيّ أخطاء.

• من التطبيق، أرسل جميع الطلبات لـredis إلى خادوم تابع.
• على هذا التابع، نفّذ الأمر SLAVEOF NO ONE. منذ النسخة 1.0.0 من Redis هذا الأمر يُخبر التابع بالتوقف عن نسخ البيانات، والبداية في التصرف كخادوم متبوع.
• على جميع التابعين المتبقّين (إذا كانوا موجودين)، تشغيل الأمر SLAVEOF hostname port سيوجههم للتوقف عن النسخ من المتبوع القديم، وتجاهل البيانات، والبداية في النسخ من المتبوع الجديد. تأكد من تغيير hostname و port بالمعلومات المناسبة من المتبوع الجديد.
• بعد حل المشكلة، قد يرجع المتبوع القديم كمتبوع رئيسي، إذا كانت الإعدادات الخاصّة بك تتطلّب ذلك.

هناك العديد من الطرق الممكنة لتنفيذ الخطوات أعلاه. ومع ذلك، الأمر يعود لك لتنفيذ أي حل تراه ملائما لبيئتك، وتأكد من اختبارها قبل أن يحدث أي فشل حقيقي.

الخطوة السادسة: إعادة الاتصال بالمتبوع الأصلي

لنرجع الاتصال بالمتبوع الأصلي. على الخادوم التابع ادخل إلى Redis وشغل الأمر التالي:

SLAVEOF your_redis_master_ip 6379

تأكد من تغيير your_redis_master_ip إلى عنوان IP الخاص بالمتبوع

إذا قمت بتشغيل الأمر INFO مجددا، يجب أن تلاحظ أنّنا عدنا إلى الإعدادات الأصليّة.

في الختام

لقد قمنا بإعداد بيئة مكونة من خادومين بنجاح، واحد يتصرف كمتبوع Redis والآخر ينسخ البيانات كتابع. بهذه الطريقة، إذا كان خادوم المتبوع يعاني من أي أخطاء أو فقد بياناتنا علي، فقد تعلمنا كيفية تبديل تابع ليصبح متبوعا كاحتياط إلى حين إصلاح المشكلة.

الخطوات التالية تتعلق ببرمجة إجراء الحماية من الخطأ التلقائي، أو ضمان اتصالات آمنة بين جميع خوادمك باستعمال حلول VPN مثل OpenVPN أو Tinc، اختبار الإجراءات والسكربتات للتحقق من صحة إعداداتك.

إضافة إلى ذلك، يجب عليك اتخاذ احتياطات عند نشر مثل هذه لإعدادات على بيئات الإنتاج. يجب أن تدرس توثيق Redis ويجب أن تفهم جيدا أي من نماذج الأمان هي الملائمة لتطبيقك. نستعمل عادة Redis كمَخزن للجلسة، وما يحتويه من معلومات قد يكون ذا قيمة لمهاجم ما. الممارسة الشائعة هي أن تمتلك هذه الخواديم إمكانية وصول فقط عبر شبكة خاصة private network.

هذه نقطة بداية بسيطة عن كيفية بناء مخزن بيانات خاص بك؛ وليس درسا شاملا عن ضبط Redis لاستخدام هندسة تابع-متبوع. إذا كان هناك أي شيء كنت ترغب في تغطيّته في هذا الدرس، اترك تعليقات أسفله، ولمزيد من المعلومات عن هذا الموضوع، فإن قسم أسئلة DevOps بالأكاديمية تعتبر أماكن جيّدة لتبدأ منها.

ترجمة -وبتصرّف- للمقال How To Configure a Redis Cluster on Ubuntu 14.04 لصاحبه Florin Dobre.

إنّ Redis هي عبارة عن ذاكرة مؤقتة cache بنمط مفتاح-قيمة key-value ومَخزَن في الذاكرة (أي قاعدة بيانات) والتي يمكن نقلها وحفظها بشكل دائم على القرص، سنشرح في هذا الدّرس كيفيّة النّسخ الاحتياطي لقاعدة بيانات Redis على خادوم Ubuntu.

يتم حفظ بيانات Redis بشكل افتراضي إلى القرص في ملف rdb.، والذي هو لقطة snapshot لنقطة في الوقت المناسب لمجموعة بيانات Redis لدينا، يتم عمل اللقطة في فواصل مُحدّدة، ويكون هذا رائعًا من أجل النسخ الاحتياطيّة لدينا.

المتطلبات الأساسية

سنحتاج لإكمال الخطوات في هذا الدّرس إلى:

• خادوم Ubuntu.
• تنصيب redis، تستطيع اتباع الإعداد الرئيسي master في هذا الدّرس لإعداد Redis (بالرغم من أنّه سيعمل بشكل جيّد مع عنقود تابع ومتبوع master-slave cluster).
• التحقق من أنّ خادوم Redis قيد التشغيل لدينا.
• إن تمّ تعيين كلمة سر لخادوم Redis -والذي ننصح به بشدّة- يكون ذلك مفيدًا، توجد كلمة السّر في ملف الإعدادات /etc/redis/redis.conf

الخطوة الأولى – إيجاد دليل بيانات Redis

تقوم Redis بتخزين بياناتها إلى دليل على خادومنا، وهو ما نريده من أجل النّسخ الاحتياطي، نحتاج في البداية لمعرفة مكان هذا الدّليل.

يوجد دليل قاعدة بيانات Redis في Ubuntu وتوزيعات لينِكس الأخرى في المسار var/lib/redis/، ولكن إن كُنّا ندير خادوم تم تغيير مكان بيانات Redis فيه، نستطيع تحديد مكانه بكتابة ما يلي:

sudo locate *rdb

وبإمكاننا بشكل بديل إيجاده عن طريق المُحث prompt الذي يُدعى redis-cli، ولفعل هذا نكتب ما يلي:

redis-cli

إن لم يكن خادوم Redis قيد التشغيل ستكون الاستجابة التي سنتلقاها هي:

Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>

وفي هذه الحالة نقوم بتشغيل Redis وإعادة الاتصال باستخدام الأوامر التالية:

sudo service redis-server start

redis-cli

سيتغير مُحث الـ Shell إلى:

127.0.0.1:6379>

في الوقت الذي نكون متصلين فيه إلى Redis سيقوم الأمران التاليان بالاستيثاق authenticate معه والحصول على دليل البيانات:

127.0.0.1:6379> auth insert-redis-password-here
127.0.0.1:6379>
127.0.0.1:6379> config get dir

يجب أن يكون خَرْج الأمر الأخير هو دليل بيانات Redis لدينا:

1) "dir"
2) "/var/lib/redis"

نلاحظ دليل Redis لدينا فإن كان مختلفًا عن الدّليل الظاهر هنا فيجب أن نحرص على استعماله خلال هذا الدّرس.

نستطيع الآن الخروج من واجهة سطر الأوامر لقاعدة البيانات:

127.0.0.1:6379> exit

نتحقّق من أنّ هذا هو الدّليل الصحيح:

ls /var/lib/redis

ينبغي أن نرى ملف dump.rdb وهو عبارة عن بيانات Redis، إن تمّ تمكين appendonly فسنرى ملف يُدعى appendonly.aof أو حتى أي ملف aof. آخر، والذي يحتوي على سجل لجميع عمليّات الكتابة التي تم تلقّيها بواسطة الخادوم.

قم بقراءة هذا المنشور حول استمرار Redis persistence من أجل النقاش حول الاختلافات بين هذين الملفين.

بشكل مُبسَّط فإنّ الملف rdb. هو اللقطة الحاليّة، والملف aof. يقوم بحفظ تاريخ Redis، وكلاهما يستحقّان أخذ نسخة احتياطيّة عنهما.

سنبدأ فقط بالملف rdb. وننتهي بنسخة احتياطيّة تلقائيّة لكلا الملفين.

الخطوة الثانية (اختيارية) – إضافة عينة sample بيانات

سنقوم في هذا القسم بإنشاء عيّنة بيانات لتخزينها في قاعدة بيانات Redis، إن كنتَ تملك مٌسبقًا بيانات على خادومك تستطيع النسخ الاحتياطي للمحتوى الموجود حاليًّا.

نقوم بتسجيل الدخول من خلال واجهة سطر الأوامر لقاعدة البيانات:

redis-cli

نقوم بالاستيثاق بكتابة ما يلي:

127.0.0.1:6379> auth insert-redis-password-here

فلنقم بإضافة عيّنة بيانات، يجب أن نتلقّى استجابة OK بعد كل خطوة.

127.0.0.1:6379> SET shapes:triangles "3 sides"
127.0.0.1:6379>
127.0.0.1:6379> SET shapes:squares "4 sides"

نتأكّد من أنّه تمّت إضافة البيانات:

127.0.0.1:6379> GET shapes:triangles
127.0.0.1:6379>
127.0.0.1:6379> GET shapes:squares

وهذا هو الخَرْج output الذي يجب أن نحصل عليه:

"3 sides"
"4 sides"

ولفرض هذه التغييرات على الملف var/lib/redis/dump.rdb/ نقوم بحفظهم:

127.0.0.1:6379> save

نستطيع الآن الخروج:

127.0.0.1:6379> exit

بإمكاننا الآن إن كُنّا نرغب التّحقّق من محتويات الملف dump، يجب أن يحتوي على بياناتنا ولو أنّها في شكل مناسب للآلة أكثر:

sudo cat /var/lib/redis/dump.rdb

REDIS0006?shapes:squares4 sidesshapes:triangles3 sides??o????C

الخطوة الثالثة – النسخ الاحتياطي لبيانات Redis

حان الوقت الآن لعمل نسخة احتياطيّة بعد أن أصبحنا نعلم مكان تواجد بيانات Redis لدينا، نجد هذا الاقتباس من موقع Redis الرّسمي:

إنّ Redis ودود جدًّا من ناحية النّسخ الاحتياطي للبيانات، حيث يُمكننا نسخ ملفّات RDB أثناء تشغيل قاعدة البيانات: لا يتم تعديل ملفّات RDB أبدًا بعد إنتاجها، وتستخدم أثناء إنتاجها اسمًا مُؤقّتًا ثمّ تتم تسميتها باسمها النهائي تلقائيًّا باستخدام (rename(2 فقط عندما تكتمل اللقطة الجديدة.

إذًا نستطيع النسخ الاحتياطي أو نسخ ملف قاعدة البيانات أثناء تشغيل خادوم Redis، وعلى افتراض أنّنا نريد النسخ الاحتياطي لها إلى دليل داخل الدّليل الرئيسي لدينا فإنّ القيام بالنسخ الاحتياطي بسيط بكتابة ما يلي:

sudo cp /var/lib/redis/dump.rdb /home/sammy/redis-backup-001

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

ومع ذلك إن كان من المقبول فقدان كمية صغيرة من البيانات فإنّ النّسخ الاحتياطي لهذا الملف فقط سيعمل بشكل جيّد.

حفظ حالة قاعدة البيانات

للحصول على نسخة أحدث بكثير من بيانات Redis فمن الأفضل النفاذ إلى redis-cli، سطر أوامر Redis.

نقوم بالاستيثاق كما شرحنا في الخطوة الأولى.

ثمّ نكتب الأمر حفظ save كما يلي:

127.0.0.1:6379> save

ينبغي أن يكون الخَرْج مُشابِهًا لهذا:

OK
(1.08s)

نخرج من قاعدة البيانات.

نستطيع الآن تشغيل الأمر cp السّابق واثقين من أنّ النسّخة الاحتياطيّة هي أحدث نسخة حتى الآن بشكل كامل.

بينما يُزوِّدنا الأمر cp بنسخة احتياطيّة مرّة واحدة من قاعدة البيانات، فإنّ الحل الأنسب هو إعداد وظيفة cron تقوم بأتمتة هذه العمليّة، واستخدام أداة تستطيع تنفيذ تحديثات تزايديّة incremental updates وتستعيد البيانات إن احتجنا لذلك.

الخطوة الرابعة – إعداد التحديثات التلقائية باستخدام rdiff-backup وCron

سنقوم في هذا القسم بإعداد نسخ احتياطي تلقائي يشمل كامل دليل بيانات Redis لدينا، بما في ذلك كلا ملفي البيانات.

توجد العديد من أدوات النسخ الاحتياطي التلقائي المتاحة، سنستخدم أداة جديدة وسهلة الاستخدام تُدعى rdiff-backup.

إنّ rdiff-backup هي أداة نسخ احتياطي تعمل عبر سطر الأوامر، من المحتمل أنّ rdiff-backup غير مُثبَّتة على خادومك، لذا يجب عليك تثبيتها أولًا:

sudo apt-get install -y rdiff-backup

نستطيع الآن بعد تثبيتها أن نختبرها بالنسخ الاحتياطي لبيانات Redis لدينا إلى مجلّد في دليلنا الرئيسي، سنفترض في هذا المثال أنّ الدليل الرئيسي لدينا هو home/sammy/.

نلاحظ أنّ الدليل الهدف سيتم إنشاؤه من قبل الـ script إن لم يكن موجودًا، أي بمعنى آخر لا نحتاج إنشاءه بأنفسنا.

ومع وجود preserve-numerical-ids-- ستكون الملكيّات نفسها للمجلدات المصدر والوجهة.

sudo rdiff-backup --preserve-numerical-ids /var/lib/redis /home/sammy/redis

وكما وجدنا مع الأمر cp سابقًا فإنّ هذه نسخة احتياطيّة لمرّة واحدة، ولكنّ الذي تغيّر هو أنّنا نقوم الآن بالنسخ الاحتياطي لكامل الدليل var/lib/redis/ وباستخدام rdiff-backup.

سنقوم الآن بأتمتة النّسخ الاحتياطي باستخدام cron بحيث تحدث النسخة الاحتياطيّة في وقت مُحدّد، ولإنجاز هذا نفتح crontab النّظام:

sudo crontab -e

(إن لم تستخدم crontab على هذا الخادوم من قبل قم باختيار مُحرّر النّصوص المفضل لديك عند سؤالك عنه.)

نقوم بإضافة المُدخَل entry التالي في نهاية الملف:

0 0 * * * rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redis

سيقوم مُدخَل Cron هذا بعمل نسخة احتياطيّة لـ Redis يوميًّا عند منتصف الليل، سيعطّل التحوّل no-file-statistics-- الكتابة إلى الملف file_statistics في الدّليل rdiff-backup-data، والذي يجعل من rdiff-backup يعمل بشكل أسرع أكثر ويستخدم مساحة قرص أقل بقليل.

ونستطيع بشكل بديل استخدام هذا المُدخَل للقيام بنسخ احتياطي يومي:

@daily rdiff-backup --preserve-numerical-ids --no-file-statistics /var/lib/redis /home/sammy/redis

وكما هو مذكور سيتم عمل نسخة احتياطيّة مرّة في اليوم، لذا بإمكانك العودة غدًا من أجل اختباره لآخر مرّة، أو تستطيع بشكل مؤقّت زيادة وتيرة النّسخ الاحتياطي لكي تتأكّد من أنّه يعمل.

ولأنّ الملفّات مملوكة من قبل مستخدم النّظام redis نستطيع التحقّق من أنّها في مكانها باستخدام هذا الأمر.(تأكّد من الانتظار إلى أن يتم تحفيز بدء النسخ الاحتياطي):

ls -l /home/sammy/redis

ينبغي أن يبدو الخَرْج مُشابِهًا لما يلي:

total 20

-rw-rw---- 1 redis redis    70 Sep 14 13:13 dump.rdb
drwx------ 3 root  root  12288 Sep 14 13:49 rdiff-backup-data
-rw-r----- 1 redis redis   119 Sep 14 13:09 redis-staging-ao.aof

نمتلك الآن نُسَخ احتياطيّة يوميّة لبيانات Redis لدينا مُخزَّنة في الدّليل الرئيسي على نفس الخادوم.

الخاتمة

إنّ النّسخ الاحتياطي لبيانات Redis بالطرق المذكورة في هذا الدّرس جيّد عندما لا نمانع من النّسخ الاحتياطي للبيانات إلى دليل على نفس الخادوم.

يبقى النهج الأكثر أمانًا بالطّبع هو النّسخ الاحتياطي إلى جهاز آخر، تستطيع استكشاف المزيد من خيارات النسخ الاحتياطي بقراءة هذا الدّرس حول النُسَخ الاحتياطيّة: كيفية اختيار استراتيجية فعالة للنسخ الاحتياطي للخادوم الخاص الافتراضي VPS.

نستطيع استخدام العديد من طرق النّسخ الاحتياطي هذه مع نفس الملفّات في الدّليل var/lib/redi/.

ترجمة -وبتصرّف- لـ How To Back Up Your Redis Data on Ubuntu 14.04 لصاحبه finid.

إنّ Redis هو عبارة عن نظام تخزين وذاكرة مؤقتة cache بنمط مفتاح-قيمة key-value مفتوح المصدر، ويتم الإشارة له أيضًا كخادوم بُنية معطيات data structure بسبب دعمه المتقدّم للعديد من أنواع البيانات كالتلبيدات Hashes، اللوائح lists، المجموعات sets والخرائط الثنائيّة Bitmaps من بين الخواديم الأخرى، يدعم أيضًا الحشد clustering والذي يجعل منه مُستخدَمًا عادةً في البيئات ذات التوافر العالي والقابلة للتطوير.

سنشاهد في هذا الدّرس كيفيّة تثبيت وإعداد خادوم Redis خارجي لكي يتم استخدامه كمُداوِل للجلسة Session Handler من أجل تطبيق PHP يعمل على Ubuntu.

إنّ مُداوِل الجلسة مسؤول عن تخزين واسترجاع البيانات المحفوظة ضمن الجلسات، حيث تستخدم PHP افتراضيًّا الملفّات من أجل هذا، يُمكن استخدام مُداوِل الجلسة الخارجي من أجل إنشاء بيئات PHP قابلة للتطوير خلف مُوازِن الحِمل load balancer، حيث ستتصل جميع عُقَد nodes التّطبيقات إلى خادوم مركزي لتتشارك معلومات الجلسة.

المتطلبات الأساسية

سنعمل في هذا الدّرس على خادومين مُنفصلين، ومن الهام من أجل الأداء والأمان أن تتوضّع كلا Droplets الخاصّة بهما في نفس مركز البيانات مع تمكين ربط الشبكات الخاصّة Private networking، وهذا ما سنحتاجه:

• خادوم ويب PHP يقوم بتشغيل LAMP أو LEMP على Ubuntu – سنقوم بالإشارة لهذا الخادوم بـ web.
• خادوم Ubuntu آخر حيث سيتم تثبيت Redis – سنقوم بالإشارة لهذا الخادوم بـ redis.

سنحتاج نفاذ مناسب عبر SSH إلى كلا الخادومين كمستخدم اعتيادي مع صلاحيّات sudo.

نستطيع أيضًا من أجل خادوم Redis استخدام تطبيق Redis بنقرة واحدة والانتقال للخطوة الثانية.

الخطوة الأولى – تثبيت خادوم Redis

إنّ أول شيء نحتاجه هو الحصول على خادوم Redis يعمل على redis Droplet الخاصّة بنا.

سنستخدم مُدير حِزَم Ubuntu الاعتيادي مع مستودع PPA موثوق يتم تزويدنا به بواسطة Chris Lea، وهو ضروري لكي نتأكّد أنّنا نحصل على آخر إصدار مُستَقر من Redis.

كنصيحة أمان عامّة ينبغي أن نستخدم PPAs من مصادر موثوقة فقط.

نُضيف في البداية مستودع PPA بتنفيذ الأمر التالي:

sudo add-apt-repository ppa:chris-lea/redis-server

نضغط Enter للتأكيد.

نحتاج الآن لتحديث الذاكرة المؤقتة cache لمدير الحِزَم:

sudo apt-get update

فلنقم أخيرًا بتثبيت Redis بتنفيذ الأمر التالي:

sudo apt-get update

ينبغي الآن أن يكون تم تثبيت Redis على خادومنا، ولاختبار التثبيت نُجرِّب هذا الأمر:

redis-cli ping

سيقوم هذا الأمر بالاتصال إلى نموذج instance من Redis يعمل على localhost على المنفذ 6379، ويجب أن نتلقّى PONG كاستجابة.

الخطوة الثانية – ضبط Redis لكي يقبل اتصالات خارجية

يسمح Redis بالاتصال فقط إلى localhost والذي يعني بشكل أساسي أنّنا نملك النفاذ إليه فقط من داخل الخادوم حيث تمّ تثبيت Redis، نحتاج إلى تغيير هذه الإعدادات للسماح بالاتصالات التي تأتي من خواديم أخرى على نفس الشبكة الخاصّة مثل الخادوم redis.

إنّ أول شيء يجب علينا فعله هو معرفة عنوان IP الجهاز Redis على الشبكة الخاصّة، ينبغي تنفيذ الخطوات التالية على الخادوم redis.

نقوم بتنفيذ الأمر ifconfig للحصول على معلومات حول واجهات شبكتنا:

sudo ifconfig

ينبغي أن نتلقّى خَرْجًا Output مُشابِهًا لما يلي:

eth0     Link encap:Ethernet HWaddr 04:01:63:7e:a4:01
         inet addr:188.166.77.33 Bcast:188.166.127.255 Mask:255.255.192.0
         inet6 addr: fe80::601:63ff:fe7e:a401/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
         RX packets:3497 errors:0 dropped:0 overruns:0 frame:0
         TX packets:3554 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:4895060 (4.8 MB) TX bytes:619070 (619.0 KB)

eth1     Link encap:Ethernet HWaddr 04:01:63:7e:a4:02
         inet addr:10.133.14.9 Bcast:10.133.255.255 Mask:255.255.0.0
         inet6 addr: fe80::601:63ff:fe7e:a402/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
         RX packets:8 errors:0 dropped:0 overruns:0 frame:0
         TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:648 (648.0 B) TX bytes:578 (578.0 B)

فلنبحث عن inet_addr المُخصَّص للواجهة eth1، في هذه الحالة نجده 10.133.14.9، وهذا هو عنوان IP الذي سنستخدمه لاحقًا للاتصال إلى الخادوم redis من الخادوم web.

نفتح الملف etc/redis/redis.conf/ باستخدام مُحرِّر سطر الأوامر command line editor المُفضَّل لدينا ونبحث عن السّطر الذي يحتوي على التّعريف bind، يجب أن نُضيف عنوان IP للشبكة الخاصّة لدينا إلى هذا السّطر كما يلي:

sudo vim /etc/redis/redis.conf

etc/redis/redis.conf/

bind localhost 10.133.14.9

إن وجدنا 127.0.0.1 بدلًا من localhost فليس هناك مشكلة، فقط نضيف عنوان IP الخاص لدينا بعد ما هو موجود.

نحتاج الآن لإعادة تشغيل الخدمة Redis لتطبيق التغييرات:

sudo service redis-server restart

إن قمنا بتثبيت Redis باستخدام تطبيق النقرة الواحدة فسيكون اسم الخدمة redis بدلًا من redis-server. ولإعادة تشغيلها نكتب الأمر:

sudo service redis restart

بعد هذه التغييرات سيكون أي خادوم داخل نفس الشّبكة الخاصّة قادرًا على الاتصال إلى نموذج Redis.

الخطوة الثالثة – تعيين كلمة سر لخادوم Redis

لإضافة طبقة أمان إضافيّة إلى تثبيت Redis لدينا فنحن نُشجِّع على تعيين كلمة سر للنفاذ إلى بيانات الخادوم، سنقوم بتحرير نفس ملف الإعدادات الذي قمنا بتحريره في الخطوة السّابقة etc/redis/redis.conf/:

sudo vim /etc/redis/redis.conf

نقوم الآن بإلغاء التّعليق uncomment عن السّطر الذي يحتوي على requirepass ونضع كلمة سر قويّة:

etc/redis/redis.conf/

requirepass yourverycomplexpasswordhere

نعيد تشغيل خدمة Redis لكي يتم تطبيق التغييرات:

sudo service redis-server restart

الخطوة الرابعة – اختبار الاتصال إلى Redis والاستيثاق Authentication

لكي نتأكّد من أنّ كافّة التغييرات تعمل كما هو متوقّع نقوم بالاتصال إلى خدمة Redis من داخل الجهاز redis:

redis-cli -h 10.133.14.9

المخرجة:

10.133.14.9:6379>

بالرغم من أنّه ليس من الإجباري هنا تحديد المُعامِل host (بما أنّنا نتصل من localhost)، فقد قمنا بذلك للتأكّد من أنّ خدمة Redis تقبل الاتصالات الموجّهة إلى واجهة الشّبكة الخاصّة.

إن كُنّا قد عرّفنا كلمة سر وحاولنا الآن النفاذ إلى البيانات ينبغي أن نتلقّى خطأ AUTH:

10.133.14.9:6379> keys *

المخرجة:

(error) NOAUTH Authentication required.

نحتاج من أجل الاستيثاق أن نقوم فقط بتنفيذ الأمر AUTH مع تزويده بنفس كلمة السّر التي عرّفناها في الملف etc/redis/redis.conf/:

10.133.14.9:6379> AUTH yourverycomplexpasswordhere

ينبغي أن نتلقّى استجابة OK، والآن إن قمنا بتنفيذ الأمر:

10.133.14.9:6379> keys *

يجب أن يكون الخَرْج مُشابِهًا لما يلي:

المخرجة:

(empty list or set)

يعني هذا الخَرْج فقط أنّ خادوم Redis لدينا فارغ، وهو ما كُنّا نتوقّعه تمامًا، حيث أنّ الخادوم web ليس مُعدًّا بعد لاستخدام خادوم Redis هذا كمداوِل للجلسة.

فلنحافظ على جلسة SSH هذه مفتوحة ومتّصلة إلى redis-cli بينما نقوم بتنفيذ الخطوات التالية، سنعود إلى المُحِث prompt redis-cli لكي نتحقّق من أنّه يتم تخزين بيانات الجلسة بشكل مناسب، وذلك بعد أن نقوم بالتغييرات الضروريّة للخادوم web.

الخطوة الخامسة – تثبيت امتداد Redis Extension على الخادوم web

يجب تنفيذ الخطوات التالية على الخادوم web، نحتاج إلى تثبيت الامتداد PHP Redis وإلّا لن تكون PHP قادرة على الاتصال إلى الخادوم Redis.

في البداية نقوم بتحديث الذاكرة المؤقتة لمدير الحِزَم بتنفيذ الأمر التالي:

sudo apt-get update

نقوم بعدها بتثبيت الحِزمَة php5-redis:

sudo apt-get install php5-redis

ينبغي الآن أن يكون الخادوم web قادرًا على الاتصال إلى Redis.

الخطوة السادسة – تعيين Redis كمداول الجلسة الافتراضي على الخادوم web

نحتاج الآن لتحرير الملف php.ini على الخادوم web لتغيير مُداوِل الجلسة الافتراضي لـ PHP، يعتمد مسار الملف على استخدامنا LAMP أو LEMP، ففي LAMP على Ubuntu يكون المسار عادةً في etc/php5/apache2/php.ini/، وفي LEMP على Ubuntu يكون المسار عادةً في etc/php5/fpm/php.ini/.

إن لم نكن متأكّدين من مسار الملف php.ini نستطيع إيجاده بطريقة سهلة باستخدام الدالّة ()phpinfo، فقط نقوم بوضع الشيفرة code التالية في ملف نسمّيه info.php داخل دليل الويب الجذري root:

<?php
phpinfo();

عند الوصول للـ script من متصفحنا ننظر إلى السطر الذي يحتوي على ملف الإعدادات الذي تمّ تحميله، ينبغي أن نجد المسار الصحيح للملف php.ini قد تمّ تحميله.

يجب ألّا ننسى إزالة الملف info.php بعد الانتهاء من هذا، لأنّه يحتوي على معلومات حسّاسة حول البيئة لدينا.

نفتح الملف php.ini ونبحث عن السّطر الذي يحتوي على session.save_handler، إنّ القيمة الافتراضيّة له هي files، ينبغي أن نقوم بتغييرها إلى redis.

على بيئة LAMP:

sudo vim /etc/php5/apache2/php.ini

على بيئة LEMP:

sudo vim /etc/php5/fpm/php.ini

etc/php5/fpm/php.ini/

session.save_handler = redis

ينبغي أن نجد الآن السّطر الذي يحتوي على session.save_path، نقوم بإلغاء التعليق عنه وتغيير قيمته بحيث تحتوي مقطع string اتصال Redis، يجب أن يتّبع المحتوى النَّسَق التالي كله في سطر واحد:

tcp://IPADDRESS:PORT?auth=REDISPASSWORD

etc/php5/fpm/php.ini/

session.save_path = "tcp://10.133.14.9:6379?auth=yourverycomplexpasswordhere"

نحتاج فقط إلى تزويد المُعامِل auth إن كُنّنا قد أعددنا كلمة سر عند ضبط Redis.

نحفظ الملف ونعيد تشغيل خدمة php.

على بيئة LAMP:

sudo service apache2 restart

على بيئة LEMP:

sudo service php5-fpm restart

الخطوة السابعة – اختبار مداولة Redis للجلسة

لكي نتأكّد من أنّ الجلسات لدينا يتم الآن مُداوَلتها من قبل Redis نحتاج PHP script أو تطبيق يقوم بتخزين المعلومات في الجلسات، سنستخدم Script بسيط يقوم بتنفيذ عدّاد Counter، حيث تتم زيادة الرقم كلّما أعدنا تحميل الصّفحة.

ننشئ ملف يُدعى test.php على الخادوم web ونضعه داخل المجلّد الجذر للمستند document root folder:

sudo vim /usr/share/nginx/html/test.php

لا يجب أن ننسى تغيير usr/share/nginx/html/ بحيث يكون مسار جذر المستند لدينا.

usr/share/nginx/html/test.php/

<?php

//simple counter to test sessions. should increment on each page reload.
session_start();
$count = isset($_SESSION['count']) ? $_SESSION['count'] : 1;

echo $count;

$_SESSION['count'] = ++$count;

نتوجّه في متصفحنا إلى http://web/test.php لكي نصل إلى الـ script، ينبغي أن يقوم بزيادة الرقم كلما قمنا بإعادة تحميل الصّفحة.

يجب أن نمتلك الآن معلومات الجلسة مُخزّنة على خادوم Redis، وللتحقّق من ذلك نعود إلى جلسة SSH على الجهاز redis، حيث قُمنا مُسبَقًا بالاتصال إلى خدمة Redis باستخدام redis-cli.

نقوم بجلب المحتوى مرّة أخرى باستخدام * keys:

10.133.14.9:6379> keys *

ينبغي أن نحصل على خَرْج مُشابِه لهذا:

1) "PHPREDIS_SESSION:j9rsgtde6st2rqb6lu5u6f4h83"

وهذا يُظهِر أنّه يتم تخزين معلومات الجلسة على خادوم Redis، ونستطيع الاتصال من خواديم ويب إضافيّة إلى خادوم Redis بطريقة مماثلة.

الخاتمة

إنّ Redis خدمة تخزين من نمط مفتاح-قيمة سريعة وقويّة نستطيع أيضًا استخدامها كمُداوِل للجلسة في PHP، مما يُمكّننا من الحصول على بيئات PHP قابلة للتطوير عن طريق تزويدها لنا بنظام مُوزَّع لتخزين الجلسة، وللمزيد من المعلومات حول تقييس scaling تطبيقات PHP تستطيع التحقّق من هذا الدّرس: تقييس تطبيقات PHP أفقيًّا.

ترجمة -وبتصرّف- للمقال How to Set Up a Redis Server as a Session Handler for PHP on Ubuntu 14.04 لصاحبته Erika Heidi.

مقدّمة

Redis هو عبارة عن مَخزَن قيم مفاتيح key value store مفتوح المصدر يمكنه العمل كمخزن لتخزين البيانات في الذاكرة in-memory store أو كمخزن تخزين بيانات مؤقت. Redis هو خادوم بنية بيانات data structure server يُمكن استخدامه إمّا كخادوم قاعدة بيانات لوحده أو مرتبطًا مع قاعدة بيانات أخرى مثل MySQL لتسريع بعض الأشياء، وهو ما سنشرحه في هذا الدليل.

في هذا الدليل، سيتم إعداد Redis كذاكرة تخزين مؤقت cache لووردبريس لتخفيف الحمل الزائد عن عمليات الاستعلام query التي تتم على قاعدة البيانات المُستخدمة لعرض صفحة ووردبريس. النتيجة ستكون توفير موقع ووردبريس أسرع بكثير من ذي قبل ويستخدم موارد أقل للتعامل مع قاعدة البيانات بالإضافة إلى توفير ذاكرة تخزين مؤقت مضبوطة ومستمرة. سيتم استخدام توزيعة Ubuntu 14.04 في هذا الدليل.

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

• صفحة ووردبريس الرئيسية الافتراضية من دون Redis: وقت تحميل الصفحة: 804 ميلي ثانية.
• صفحة ووردبريس الرئيسية الافتراضية مع Redis:وقت تحميل الصفحة: 449 ميلي ثانية.

تحذير: عملية التطبيق هذه لـRedis للقيام بعملية التخزين المؤقت لذاكرة ووردبريس يعتمد على سكربت script طرفٍ ثالث تم تطويره عبر طرفٍ خارجي. إذا كنتَ تريد القيام بعملية تطبيق Redis لووردبريس بنفسك فعليك أن تقوم بعمل بعض العمل الإضافي بناءً على المفاهيم التي سيتم تقديمها هنا.

Redis أو Memcached

يُعتبر Memcached أيضًا خيارًا مشهورًا لعمل ذاكرة تخزينٍ مؤقت، لكن في هذه الحالة، Redis يقوم بكل ما يستطيع Memcached القيام به بالإضافة إلى تشكيلة أوسع من المميزات. هذه الصفحة على Stack Overflow بها بعض المعلومات العامة عن المقارنة بينهما.

كيف يعمل التخزين المؤقت caching؟

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

عملية تطبيق Redis المُستخدمة في هذا الدليل ستجعله يعمل ككائن تخزينٍ مؤقت مستمر (persistent object cache) لووردبريس (دون انتهاء). يعمل كائن التخزين المؤقت عبر تخزين عمليات استعلام SQL التي يحتاجها ووردبريس لتحميل الصفحات مؤقتًا في الذاكرة.

عندما يتم تحميل أيّ صفحة، يتم توفير النتائج الناتجة عن عمليات الاستعلام في SQL من الذاكرة باستخدام Redis, لذا فإنه لا توجد هناك حاجة لعمل عملية استعلام جديدة من قاعدة البيانات من جديد. وهو ما يعطي سرعةً أكبر في تحميل الصفحات بالإضافة إلى حملٍ أقل من طرف الخادوم على موارد قاعدة البيانات. إذا كان هناك استعلام غير متوفر في Redis، فإنّ قاعدة البيانات تقوم بتوفير نتيجة عملية الاستعلام تلك ويقوم Redis بإضافة تلك النتيجة إلى ذاكرته المؤقتة.

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

إذا واجهتَ مشاكل مع التخزين المؤقت، فإنه بإمكانك إلغاء صلاحية ذاكرة التخزين المؤقت الخاصة بـRedis باستخدام أمر flushall عبر سطر الأوامر الخاص بـRedis:

redis-cli

بمجرد أن ترى سطر الأوامر، طبّق:

flushall

مرجع إضافي: التوثيق الخاص بكائن التخزين المؤقت لووردبريس.

المتطلبات

قبل البدء بهذا الدليل، ستحتاج إلى إعداد مستخدمٍ بصلاحيات الجذر (sudo) بالإضافة إلى تثبيت ووردبريس.

• خادوم Ubuntu 14.04 (من المستحسن أن تكون بذاكرة عشوائية 1 جيجابايت أو أعلى).

• إضافة  مستخدم بصلاحيات الجذر (sudo).

• تثبيت ووردبريس. 

الخطوة الأولى – تثبيت Redis

بهدف استخدام Redis مع ووردبريس، فإننا بحاجة إلى تثبيت حزمتين: redis-server و php5-redis. حزمة redis-server توفرّ تطبيق Redis نفسه، بينما حزمة php5-redis تقوم بتوفير امتداد PHP للتطبيقات المكتوبة بـPHP مثل ووردبريس للتعامل مع Redis.

لتثبيت هذه البرمجيات:

sudo apt-get install redis-server php5-redis

الخطوة الثانية – إعداد Redis كذاكرة تخزين مؤقت

يمكن لـRedis أن يعمل إمّا كمخزن قاعدة بيانات NoSQL أو كذاكرة تخزينٍ مؤقت. في هذا الدليل وهذه الحالة بالضبط، سيتم ضبط Redis كذاكرة تخزينٍ مؤقت. الإعدادات التالية ستكون مطلوبة بهدفِ فعلِ ذلك.

حرر الملف /etc/redis/redis.conf عن طريق الأمر:

sudo nano /etc/redis/redis/conf

وقم بإضافة السطور التالية لنهاية الملف:

maxmemory 256mb
maxmemory-policy allkeys-lru

ثم احفظ الملف.

الخطوة الثالثة – حمّل سكربت ذاكرة التخزين المؤقت الخلفي لـRedis

تم تطوير سكربت الـPHP هذا لووردبريس بواسطة Eric Mann. وهو عبارة عن سندٍ خلفي backend لكائن ذاكرةِ التخزين المؤقت من Redis لووردبريس.

عليك تحميل سكربت object-cache.php. عملية التحميل هذه ستتم من خواديم DigitalOcean، ولكن هذا السكربت هو سكربت تم تطويره بواسطة طرفٍ ثالث. يجب عليك قراءة التعليقات داخل السكربت لمعرفة كيفية عمله.

لتحميل سكربت الـPHP:

wget https://assets.digitalocean.com/articles/wordpress_redis/object-cache.php

قم بنقل الملف إلى مسار /wp-content داخل مجلد ووردبريس الخاص بك:

sudo mv object-cache.php /var/www/html/wp-content/

قد يكون مسار المجلد (باللون الأحمر) مختلفًا اعتمادًا على طريقة تثبيتك لووردبريس.

الخطوة الرابعة – فعّل إعدادات التخزين المؤقت في ملف wp-config.php

الآن، قم بتحرير ملف wp-config.php لإضافة ملحِ مفتاحِ ذاكرةِ تخزينٍ مؤقت (cache key salt) مع اسم موقعك (أو أيّ سلسلة string تريدها):

nano /var/www/html/wp-config.php

ثم أضف السطر الآتي إلى نهاية قسم * Authentication Unique Keys and Salts:

define('WP_CACHE_KEY_SALT', 'example.com');

يمكنك استخدام اسم النطاق الخاص بك domain أو أي سلسلة نصية كملح salt.

ملاحظة: للمستخدمين الذين يستضيفون أكثر من موقع ووردبريس واحد، يمكن لكلِ موقعٍ أن يتشارك باستخدام تثبيت Redis واحد طالما أن كلّ موقعٍ منفصل يمتلك ملحَ مفتاح ذاكرة التخزين المؤقت الخاص به.

أيضًا، قم بإضافة السطر التالي بعد سطر WP_CACHE_KEY_SALT لإنشاء ذاكرة تخزينٍ مؤقت مستمرة مع مُلحق كائن ذاكرة التخزين المؤقت لـRedis:

define('WP_CACHE', true);

في النهاية، يجب أن يكون ملفّك هكذا:

 * Authentication Unique Keys and Salts.

. . .

define('NONCE_SALT',       'put your unique phrase here');

define('WP_CACHE_KEY_SALT', 'example.com');
define('WP_CACHE', true);

احفظ الملف وأغلقه.

الخطوة الخامسة – قم بإعادة تشغيل Redis و Apache

أخيرًا، قم بإعادة تشغيل redis-service و apache2. لإعادة تشغيل Redis:

sudo service redis-server restart

لإعادة تشغيل Apache:

sudo service apache2 restart

أيضًا قم بإعادة تشغيل php5-fpm إذا كنتَ تستخدمها; هذا ليس جزءًا أساسيًا من عملية التثبيت، وعلى كل حال، لفعل ذلك طبّق:

sudo service php5-fpm restart

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

مراقبة Redis باستخدام redis-cli

لمراقبة Redis، استخدم أمر redis-cli كالتالي:

redis-cli monitor

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

بالأسفل مثال على خرجٍ من موقع ووردبريس مضبوط باستخدام هذا الدليل عبر Redis:

OK
1412273195.815838 "monitor"
1412273198.428472 "EXISTS" "example.comwp_:default:is_blog_installed"
1412273198.428650 "GET" "example.comwp_:default:is_blog_installed"
1412273198.432252 "EXISTS" "example.comwp_:options:notoptions"
1412273198.432443 "GET" "example.comwp_:options:notoptions"
1412273198.432626 "EXISTS" "example.comwp_:options:alloptions"
1412273198.432799 "GET" "example.comwp_:options:alloptions"
1412273198.433572 "EXISTS" "example.comwp_site-options:0:notoptions"
1412273198.433729 "EXISTS" "example.comwp_:options:notoptions"
1412273198.433876 "GET" "example.comwp_:options:notoptions"
1412273198.434018 "EXISTS" "example.comwp_:options:alloptions"
1412273198.434161 "GET" "example.comwp_:options:alloptions"
1412273198.434745 "EXISTS" "example.comwp_:options:notoptions"
1412273198.434921 "GET" "example.comwp_:options:notoptions"
1412273198.435058 "EXISTS" "example.comwp_:options:alloptions"
1412273198.435193 "GET" "example.comwp_:options:alloptions"
1412273198.435737 "EXISTS" "example.comwp_:options:notoptions"
1412273198.435885 "GET" "example.comwp_:options:notoptions"
1412273198.436022 "EXISTS" "example.comwp_:options:alloptions"
1412273198.436157 "GET" "example.comwp_:options:alloptions"
1412273198.438298 "EXISTS" "example.comwp_:options:notoptions"
1412273198.438418 "GET" "example.comwp_:options:notoptions"
1412273198.438598 "EXISTS" "example.comwp_:options:alloptions"
1412273198.438700 "GET" "example.comwp_:options:alloptions"
1412273198.439449 "EXISTS" "example.comwp_:options:notoptions"
1412273198.439560 "GET" "example.comwp_:options:notoptions"
1412273198.439746 "EXISTS" "example.comwp_:options:alloptions"
1412273198.439844 "GET" "example.comwp_:options:alloptions"
1412273198.440764 "EXISTS" "example.comwp_:options:notoptions"
1412273198.440868 "GET" "example.comwp_:options:notoptions"
1412273198.441035 "EXISTS" "example.comwp_:options:alloptions"
1412273198.441149 "GET" "example.comwp_:options:alloptions"
1412273198.441813 "EXISTS" "example.comwp_:options:notoptions"
1412273198.441913 "GET" "example.comwp_:options:notoptions"
1412273198.442023 "EXISTS" "example.comwp_:options:alloptions"
1412273198.442121 "GET" "example.comwp_:options:alloptions"
1412273198.442652 "EXISTS" "example.comwp_:options:notoptions"
1412273198.442773 "GET" "example.comwp_:options:notoptions"
1412273198.442874 "EXISTS" "example.comwp_:options:alloptions"
1412273198.442974 "GET" "example.comwp_:options:alloptions"

اضغط CTRL-C لإيقاف الخرج.

هذا الأمر مفيد لرؤية الاستعلامات التي يعالجها Redis بالضبط.

الخاتمة

بعد اتّباع هذا الدليل، سيصبح ووردبريس مضبوطًا لاستخدام Redis كذاكرة تخزينٍ مؤقت على Ubuntu 14.04.

ترجمة -وبتصرّف- للمقال: How To Configure Redis Caching to Speed Up WordPress on Ubuntu 14.04