Ապրանքանիշների պահոց

Cache tags = տվյալների կախվածություններ

Cache tags նկարագրում են Drupal-ով կառավարվող տվյալներից կախվածությունները

Ինչու՞:

Կեշավորված տեգերը տրամադրում են հայտարարական եղանակ հետևելու, թե որ կեշի տարրերը կախված են Drupal-ով կառավարվող որոշ տվյալներից:

Սա կարևոր է բովանդակության կառավարման համակարգերի/ֆրեյմվորքների համար, ինչպիսին է Drupal-ը, որովհետև նույն բովանդակությունը կարող է բազմակի կերպ օգտագործվել: Այլ կերպ ասած՝ հնարավոր չէ նախապես իմանալ, թե որտեղ և ինչպես է օգտագործվելու տվյալ բովանդակությունը։ Բովանդակության օգտագործման ցանկացած տեղ կարող է կեշավորվել։ Սա նշանակում է, որ նույն բովանդակությունը կարող է կեշավորվել բազմաթիվ վայրերում։ Սա մեզ հանգեցնում է հայտնի մի արտահայտության. Ինֆորմատիկայում գոյություն ունեն միայն երկու լուրջ խնդիր՝ կեշի անվավերացում և անունների շնորհում. այսինքն՝ ինչպես աննալիզացնել բոլոր կեշի տարրերը, որտեղ օգտագործվում է բովանդակությունը:

Նշում. Drupal 7-ն առաջարկում է կեշի տարրերի անվավերացման 3 տարբերակ՝ մեկ կոնկրետ CID-ի անվավերացում, CID-ների նախածանցով անվավերացում կամ ամբողջ կեշի բինի անվավերացում: Դրանքից ոչ մեկը թույլ չի տալիս անվավերացնել այն կեշի տարրերը, որոնք պարունակում են փոփոխված էկզեմպլյար, քանի որ դա հնարավոր չէր իմանալ:

Ո՞րն է:

Կեշի թեգը տող է:

Կեշավորված թեգերը փոխանցվում են տողերի հավաքածուներով (հավաքածուների հերթականությունը կարևոր չէ), ուստի դրանք տպվում են որպես string[]. Հավաքածուներ, որովհետև մեկ կեշի տարրը կարող է կախված լինել բազմաթիվ թեգերից:

Սինթաքսիս

Համաձայնության համաձայն, դրանք ունեն thing:identifier ձևաչափը, և երբ չկա բազմաթիվ էկզեմպլյարների հասկացություն, ունեն ձևաչափ thing: Միակ կանոնը՝ չեն կարող ունենալ բացատներ:

Սկզբունքորեն պարտադիր սինթաքս չի կան:

Օրինակներ՝

• node:5 - կեշի թեգ Node հանգույցի համար 5 (անվավերանում է երբևիցե այն փոխվի)
• user:3 - կեշի թեգ User 3 օբյեկտի համար (անվավերանում է երբ փոխվի)
• node_list - կեշի թեգերի ցանկ Node օբյեկտների համար (անվավերանում է երբ որևէ Node օբյեկտ թարմացվի, ջնջվի կամ ստեղծվի, այսինքն՝ երբ կարող է անհրաժեշտ լինել փոփոխել հանգույցների ցանկը): կիրառելի է ցանկացած էկզեմպլյարի տեսակին հետևյալ ձևաչափով՝ {entity_type}_list.
• config:system.performance - կեշի թեգ system.performance կոնֆիգուրացիայի համար
• library_info - կեշի թեգ ակտիվ գրադարանների համար

Հիմնական կեշի թեգեր

Drupal-ով կառավարվող տվյալները բաժանվում են 3 կատեգորիաների՝

• էկզեմպլյարներ (entities) - ունեն կեշի թեգեր այս տեսքով <entity type ID>:<entity ID>, ինչպես նաև <entity type ID>_list և <entity type ID>_list:<bundle>՝ էկզեմպլյարների ցանկերի անվավերացման համար: Կոնֆիգուրացիոն օբյեկտները օգտագործում են կոնֆիգի հիմնական օբյեկտի կեշի թեգը:
• կոնֆիգուրացիա - ունեն կեշի թեգեր config:<configuration name> ձևաչափով
• հատուկ "custom" (օրինակ՝ library_info)

Drupal-ը ինքնաբերաբար տրամադրում է կեշի թեգեր էկզեմպլյարների և կոնֆիգուրացիայի համար - տես Entity բազային դասը և ConfigBase բազային դասը (բոլոր կոնկրետ էկզեմպլյարների և կոնֆիգուրացիայի օբյեկտների տեսակները ժառանգվում են դրանցից):

Չնայած շատ օբյեկտների տեսակներ հետևում են կանխատեսելի կեշի թեգերի ձևաչափին <entity type ID>:<entity ID>, երրորդ կողմի կոդը չպետք է դրան վստահի: Փոխարենը, պետք է ստանա կեշի թեգերը անվավերացնելու համար տվյալ օբյեկտի համար, օգտագործելով մեթոդը : :getCacheTags(), օրինակ՝ $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags() և այլն:

Բացի այդ, կարող է պահանջվել անվավերացնել նաև կեշերը, որոնք հիմնված են ցանկերի վրա, որոնք կախված են տվյալ էկզեմպլյարից (օրինակ՝ թարմացնել ռենդերացված HTML-ը ցանկի համար, երբ նոր էկզեմպլյար է ստեղծվում): դա կարելի է անել EntityTypeInterface::getListCacheTags() մեթոդով, ապա անվավերացնել այդ մեթոդից վերադարձված բոլոր թեգերը՝ միասին օբյեկտի սեփական թեգերի հետ: Drupal 8.9-ից սկսած (փոփոխության հայտարարություն) փաթեթավորված էկզեմպլյարները ավտոմատ ունեն ավելի կոնկրետ կեշի թեգ, որը ներառում է իրենց փաթեթը, ապահովելու ավելի նպատակային ցանկերի անվավերացում:

Բացի այդ, հնարավոր է սահմանել օգտատիրոջ կողմից որոշված, ավելի կոնկրետ կեշի թեգեր օբյեկտների հատկանիշների հիման վրա, օրինակ՝ տերմինի սղության համար ցուցադրող ցանկերի դեպքում, որոնք ցույց են տալիս տերմինով օբյեկտներ: Նման թեգերի անվավերացումը կարելի է կատարել օգտատիրոջ նախադրամարկղ/ջնջում հարթակներում՝ օրինակ՝

function yourmodule_node_presave(NodeInterface $node) {
  $tags = [];
  if ($node->hasField('field_category')) {
    foreach ($node->get('field_category') as $item) {
      $tags[] = 'mysite:node:category:' . $item->target_id;
    }
  }
  if ($tags) {
    Cache::invalidateTags($tags);
  }
}

Այս թեգերը կարելի է օգտագործել կոդում և Views-ում՝ օգտագործելով Views Custom Cache Tag մոդուլը:

Նշում. Հիմա չկա API, որով կարելի է ստանալ առանձին փաթեթներ և ավելի կոնկրետ կեշի թեգեր օբյեկտից կամ այլ օբյեկտից: Դա կապված է այն բանի հետ, որ որոշող օբյեկտը՝ որ կեշի թեգերը նպատակային են կոնկրետ ցանկի/հարցման համար, կախված է հենց հարցումից: Վերամշակված Drupal-ի ավելի ուշ տարբերակները հավանաբար կբարելավեն կեշ-թեգերի աջակցությունը յուրաքանչյուր փաթեթի համար և, օրինակ, կներառեն դրանք էկզեմպլյարների հարցումների և Views-ի կառուցման մեջ:

Ինչպե՞ս

Կարգավորումներ

Յուրաքանչյուր կեշ-սերվեր պետք է իրականացնի CacheBackendInterface-ը, ուստի երբ կեշի տարր եք տեղադրում ::set() մեթոդով, փոխանցեք երրորդ և չորրորդ արգումենտները, օրինակ՝

$cache_backend->set(
  $cid, $data, Cache::PERMANENT, ['node:5', 'user:7']
);

Սա պահում է կեշի տարրը $cid նույնականացուցիչով անվերջ, բայց դարձնում այն ենթակա անվավերացման node:5 և user:7 թեգերով:

Անվավերացում

Կեշի թեգերով նշված տարրերը անվավերանում են cache_tags.invalidator:invalidateTags() (կամ եթե չեք կարող ներարկել cache_tags.invalidator ծառայությունը՝ օգտագործեք Cache::invalidateTags()), որը ստանում է կեշի թեգերի հավաքածու (string[]):

Նշում. դա անվավերացնում է բոլոր կեշի տարրերը նշված թեգերով բոլոր կեշի բիներում: Այդ պատճառով էլ թեգերով անվավերացնելը անհետևանք է բիների միջեւ, քանի որ փոփոխված տվյալները, որոնց թեգերը անվավեր են, կարող են կախված լինել մյուս բիների կեշի տարրերից:

Տվյալների ստուգում (դեբագ)

Բոլոր նշվածներն օգտակար են, երբ փորձում եք ստուգել կեշավորված բովանդակություն: Բայց կա ևս մեկ կարևոր բան. եթե ինչ-որ տարրը կեշավորվում է հետևյալ թեգերով ['foo', 'bar'], ապա կեշի տարրը կունենա թեգերի սյուն (եթե ենթադրենք, որ դա DB կեշ է) այս տեսքով.

bar foo

Ասածն այն է՝

• կեշի թեգերը բաժանված են բացատով
• կեշի թեգերը դասավորված են այբբենական կարգով

Սա հեշտացնում է կեշի վերլուծությունը և դեբագը:

Վերնագրեր (դեբագ)

Վերջապես, հեշտ է տեսնել, թե որ կեշի թեգերից է կախված կոնկրետ պատասխան (և հետևաբար երբ այն անվավեր է լինում)` պարզապես նայելով X-Drupal-Cache-Tags հեդերին:

(Այստեղից էլ է գալիս բացատների արգելքը. Քանի որ X-Drupal-Cache-Tags հեդերը, ինչպես և շատ HTTP հեդերներ, օգտագործում է բացատները արժեքները բաժանելու համար):

Նշում. Եթե չեք տեսնում այս հեդերները, պետք է կարգավորեք Drupal-ի զարգացման միջավայրը:

Համակցում հակադարձ պրոքսիների հետ

Փոխարենը կեշավորելու Drupal-ի պատասխանը և անվավերացնելու այն կեշի թեգերով, դուք կարող եք կեշավորել պատասխանները հակադարձ պրոքսի (Varnish, CDN և այլն) վրա և անվավերացնել կեշավորված պատասխանները՝ օգտագործելով դրանց հետ կապվող կեշի թեգերը: Որպեսզի հակադարձ պրոքսիները իմանան, թե որ թեգեր են կապված յուրաքանչյուր պատասխանին, դուք կարող եք ուղարկել կեշի թեգերը հեդերի միջոցով:

Իսկապես, ինչպես Drupal 8-ն ուղարկում է X-Drupal-Cache-Tags հեդերը դեբագի համար, այնպես էլ կարող է ուղարկել Surrogate-Keys հեդեր՝ արժեքներ բաժանված բացատներով, ինչպես սպասվում է որոշ CDN-ներից, կամ Cache-Tag հեդեր՝ արժեքներ բաժանված ստորակետներով, ինչպես սպասվում է մյուս CDN-ներից: Եվ սա կարող է լինել նաև ինքնավար հակադարձ պրոքսի սերվեր, ոչ միայն կոմերցիոն CDN ծառայություն:

Ընդհանուր առմամբ խորհուրդ է տրվում, որ և ձեր վեբ սերվերն ու հակադարձ պրոքսին աջակցեն մինչև 16 KB հեդերների արժեքներին:

1. HTTP-ն տեքստային է: Կեշի թեգերը հիմնված են տեքստի վրա: Հակադարձ պրոքսիները կարող են ազատ ներկայացնել կեշի թեգերը այլ տվյալների կառուցվածքներում: 16 KB արժեքի սահմանը ընտրվել է երկու գործոնների հիման վրա՝ A) ապահովելու, որ աշխատի 99%-ում, B) գործնականում հասանելի է: Սովորական վեբ սերվերները (Apache) և սովորական CDN-ները (Fastly) աջակցում են մինչև 16 KB արժեքներ: Սա մոտավորապես նշանակում է 1000 կեշի թեգ, ինչը բավական է 99%-ի դեպքերում:
2. Կեշի թեգերի քանակը շատ տարբեր է կայքից և կոնկրետ պատասխանից կախված: Եթե պատասխանն կախված է շատ բաներից, կեշի թեգերը շատ կլինեն: Ավելի քան 1000 կեշի թեգ ունեցող պատասխանները հազվադեպ են:
3. Իհարկե, այս ուղեցույցը (~1000 թեգ/պատասխան) կարող է զարգանալ հետագայում, քանի որ A) ավելի ու ավելի շատ իրական ծրագրեր կիրառում են այն, B) համակարգերը հատուկ օգտագործում և կառուցում են այս հնարավորության վրա:

Վերջում՝ ցանկացած 1000 կեշի թեգերից ավելի մեծ քանակ ցույց է տալիս ավելի խոր խնդիր՝ պատասխանն ավելի բարդ է և պետք է բաժանել: Դուք կարող եք անցնել այս թիվը Drupal-ում, բայց դա կարող է պահանջել ձեռքի կարգավորում, որը ընդունելի է բացառիկ բարդ դեպքերում: Պատահում է նույնիսկ շատ ավելի քիչ քան 1000 թեգերի դեպքում:

Կարդացեք Varnish-ի հետ կեշի թեգերի օգտագործման փաստաթուղթը:

Պատճենվել է, որ CDN-ները աջակցում են թեգերով կեշի անվավերացում/մաքրման հնարավորությունը՝

CloudFlare
Fastly
KeyCDN
Akamai

Ներքին էջի կեշ

Drupal 8-ում կեշի թեգերի համապարփակ օգտագործումը հնարավորություն է տալիս Drupal 8-ին հասանելի լինել նախաձեռնված ներքին էջի կեշով, որը ոչ այլ ինչ է, քան ներդրված հակադարձ պրոքսի:

Դիտարկեք նաև

• Ռենդերավորման զանգվածների կեշավորման կարողությունը
• Կեշի կոնտեքստներ
• Կեշի առավելագույն տարիքը