قبلا در این سری مقالات، اهمیت شبکه‌های گرافی، مفاهیم گراف، تجسم گراف و روش‌های شناسایی تقلب مبتنی بر گراف را پوشش دادیم. در این مقاله، در مورد شناسایی خودکار انواع جدید رفتارهای تقلبی و برخورد سریع با آنها صحبت خواهیم کرد.

یکی از چالش‌های شناسایی تقلب این است که کلاهبرداران حوزه تقلب را همواره به نوعی ابتکاری در راه‌های انجام تقلب‌ها (MO به اختصار) ارتقا می‌دهند، یعنی روش عملیات آنها. مدل‌های یادگیری ماشین که با استفاده از داده‌های تاریخی آموزش داده شده‌اند، ممکن است قادر به تشخیص MO جدید نباشند، زیرا این‌ها الگوهای جدیدی هستند که در داده‌های آموزش موجود موجود نیستند. برای بهبود دفاع‌های امنیتی موجود در Grab و محافظت از کاربران خود در برابر این MO‌های جدید، به یک مدل یادگیری ماشین نیاز داشتیم که بتواند به طور سریع آن‌ها را شناسایی کرده و بدون نیاز به هیچ نوع نظارت برچسبی عمل کند، یعنی یک مدل یادگیری بدون نظارت به جای مدل یادگیری با نظارت معمول.

برای مقابله با این موضوع، ما یک مدل یادگیری ماشین داخلی برای شناسایی الگوهای ناهنجار در گراف‌ها توسعه دادیم که منجر به کشف MO تقلبی جدید شده است. ابتدا تمرکز ما در GrabFood و GrabMart بود که در آنجا تعاملات بین مصرف‌کنندگان و تجار را نظارت می‌کردیم. این تعاملات را به عنوان یک گراف دو قسمتی (نوعی گراف برای مدل کردن تعاملات بین دو گروه) مدل کردیم و سپس شناسایی ناهنجاری را روی گراف انجام دادیم. مدل شناسایی ناهنجار داخلی خود را نیز در کنفرانس مشترک بین‌المللی شبکه‌های عصبی (IJCNN) 2023، یک کنفرانس علمی برجسته در حوزه شبکه‌های عصبی، یادگیری ماشین و هوش مصنوعی، ارائه دادیم.

در این وبلاگ، ما درباره مدل و کاربرد آن در Grab صحبت خواهیم کرد. برای مخاطبان علاقه‌مند که جزئیات مدل ما را بخوانند، می‌توانید به مقاله ما در زیر دسترسی پیدا کنید. توجه کنید که اگرچه ما مدل خود را برای شناسایی ناهنجاری در GrabFood و GrabMart پیاده‌سازی کرده‌ایم، اما این مدل برای اهداف عمومی طراحی شده است و قابل استفاده در گراف‌های تعامل بین هر دو گروه است.

قبل از ورود به نحوه کار کرد مدل ما، مهم است که فرآیند ساختار گراف در برنامه ما را دریابید، زیرا مدل فرض می‌کند گراف‌ها به صورت استاندارد در دسترس باشند.

ساخت گراف

ما تعاملات بین مصرف‌کنندگان و تجار در پلتفرم‌های GrabFood و GrabMart را به عنوان گراف‌های دو قسمتی (G) مدل کردیم، جایی که گروه اول گره‌ها (U) مصرف‌کنندگان را نشان می‌دهد، گروه دوم گره‌ها (V) تجار را نمایش می‌دهد و لبه‌ها (E) که آنها را به هم متصل می‌کند، بدین معنی است که مصرف‌کنندگان سفارش‌هایی از تجار قرار داده‌اند. گراف همچنین شامل اطلاعات معاملاتی جامع درباره مصرف‌کنندگان و تجار در قالب ویژگی‌های گره (Xu و Xv) و همچنین اطلاعات سفارش در قالب ویژگی لبه (Xe) است.

هدف مدل ناهنجاری ما شناسایی رفتارهای مشکوک در میان مصرف‌کنندگان یا تجار (شناسایی ناهنجاری سطح گره) و همچنین تعاملات سفارشات مشکوک (شناسایی ناهنجاری سطح لبه) است. همانطور که ذکر شد، این شناسایی بدون هیچ نوع نظارت برچسبی باید انجام شود.

معماری مدل

ما مدل ناهنجاری گراف خود را به عنوان یک نوع خودکدنده خودکار طراحی کردیم، با یک کدگذار و دو کدگشا - یک کدگشای ویژگی و یک کدگشای ساختار. ویژگی کلیدی مدل ما این است که یک گراف دو قسمتی با ویژگی‌های گره و لبه را به عنوان ورودی می‌پذیرد. این امر مهم است، زیرا هم ویژگی‌های گره و هم ویژگی‌های لبه اطلاعات مهمی را برای تعیین اینکه آیا برخی از رفتارها مشکوک هستند، رمز می‌کنند. بسیاری از کارهای قبلی در شناسایی ناهنجاری گراف فقط از ویژگی‌های گره پشتیبانی می‌کنند. علاوه بر این، مدل ما می‌تواند هم نمرات ناهنجاری سطح گره و هم نمرات ناهنجاری سطح لبه را تولید کند، در عوض بسیاری از کارهای قبلی فقط نمرات سطح گره را تولید می‌کنند. ما مدل خود را به نام GraphBEAN نامگذاری کرده‌ایم که مخفف شبکه‌های گراف بی قسمتی گره و لبه ویژگی دار است.

از ورودی، کدگذار سپس گراف دو قسمتی مشخصه دار را به سری از لایه‌های کانوولوشن گراف پردازش کرده و برای هر گروه گره به تصویرهای نهانی جدیدی منتج می‌شود. لایه‌های کانوولوشن گراف ما برای هر گره در هر دو گروه گره (UوV) ، و همچنین برای هر لبه در گراف، نمایش نهانی جدیدی ایجاد می‌کنند. توجه کنید که آخرین لایه کانوولوشن در کدگذار فقط نماینده‌های نهانی برای گره‌ها را تولید می‌کند، بدون تولید نماینده‌های لبه. دلیل این طراحی این است که فقط نماینده‌های نهانی برای عوامل فعال، گره‌های نماینده مصرف‌کنندگان و تجار را قرار می‌دهیم، اما نه تعامل آنها.

از نماینده‌های نهانی گره‌ها، کدگشای ویژگی مسئولیت دارد که گراف اصلی با ویژگی‌های گره و لبه را با استفاده از سری از لایه‌های کانوولوشن گراف بازسازی کند. همچنین بدین دلیل که کدگشای ساختار و پیش‌بینی شود که آیا یک لبه وجود دارد که دو گره را به هم متصل می‌کند، وظیفه ساختار رمزگشایی کردن گراف را بر عهده داشته باشد. این پیش‌بینی لبه، همچنین گراف بازسازی شده توسط کدگشای ویژگی، به مقایسه با گراف ورودی اصلی از طریق تابع خطای بازسازی منجر می‌شود.

سپس مدل با استفاده از گراف بی قسمتی ساخته شده از تراکنش‌های GrabFood و GrabMart آموزش داده می‌شود. ما از یک تابع خطای بازسازی به عنوان هدف آموزش مدل استفاده می‌کنیم. پس از اتمام آموزش، امتیاز ناهنجاری هر گره و لبه در گراف را با استفاده از مدل آموزش دیده محاسبه می‌کنیم.

محاسبه امتیاز ناهنجاری

امتیازهای ناهنجاری ما بر اساس بازسازی انجام می‌شود. طراحی امتیاز فرض می‌کند که رفتارهای طبیعی در مجموعه داده رایج هستند و بنابراین به راحتی توسط مدل قابل بازسازی هستند. از طرف دیگر، رفتارهای ناهنجار کمیاب هستند. بنابراین مدل سخت دارد آنها را بازسازی کند و بنابراین خطاهای بالایی تولید می‌کند.

مدل امتیازهای ناهنجاری را به دو نوع تولید می‌کند. اول، امتیازهای ناهنجاری سطح لبه که از خطای بازسازی لبه محاسبه می‌شوند. دوم، امتیازهای ناهنجاری سطح گره که از خطای بازسازی گره به علاوه یک تجمع بر روی امتیازهای لبه از طریق لبه‌های متصل به گره محاسبه می‌شوند. این تجمع می‌تواند یک تجمع میانگین یا حداکثر باشد.

سیستم اقدامات

در پیاده‌سازی GraphBEAN در Grab، ما یک لوله کامل از سیستم‌های شناسایی ناهنجاری و اقدامات طراحی کردیم. این یک سیستم کاملا اتوماتیک برای ساخت گراف دو قسمتی از تراکنش‌های GrabFood و GrabMart، آموزش مدل GraphBEAN با استفاده از گراف و محاسبه امتیازهای ناهنجاری است. پس از محاسبه امتیازهای ناهنجاری برای همه مصرف‌کنندگان و تجار (سطح گره)، و همچنین تمام تعاملات آنها (سطح لبه)، به طور خودکار به سیستم اقدامات ما منتقل می‌شود. اما قبل از آن، این امتیازها را از طریق یک سیستمی که زمینه مبتنی بر قاعده نظارتی است، ماfraud type taggerمی‌نامیم، منتقل می‌کند. هدف از این برچسب‌زنی، ارائه برخی از زمینه‌هاست، مانند انواع ناهنجاری‌های شناسایی شده. برخی از این برچسب‌ها، سوءاستفاده از پروموشن یا توطئه ممکن است.

هر دو امتیاز ناهنجاری و برچسب‌های نوع تقلب سپس به سیستم اقدامات ما منتقل می‌شوند. سیستم شامل دو زیرسیستم است:

سیستم اقدامات توسط کارشناسان اقدامی: کارشناسان تقلب ما ناهنجاری‌های شناسایی شده را تجزیه و تحلیل کرده و روی آنها اقدامات خاصی انجام می‌دهند، مانند تعلیق برخی از ویژگی‌های تراکنش از تجار مشکوک.سیستم اقدامات اتوماتیک: امتیازهای ناهنجاری و برچسب‌های نوع تقلب را با سیگنال‌های خارجی دیگر تلفیق کرده و به طور خودکار روی ناهنجاری‌های شناسایی شده اقداماتی انجام می‌دهد، مانند جلوگیری از استفاده از پروموشن توسط تقلبگران یا جلوگیری از وقوع تراکنش‌های تقلبی. این اقدامات بستگی به نوع تقلب و امتیازها دارند.

چه چیزی بعداز این؟

مدل GraphBEAN امکان شناسایی رفتارهای مشکوک در داده‌های گراف را بدون نیاز به نظارت برچسب فراهم می‌کند. با پیاده‌سازی مدل در پلتفرم‌های GrabFood و GrabMart، ما فهمیدیم که داشتن چنین سیستمی به ما امکان می‌دهد که به سرعت انواع جدیدی از رفتارهای تقلبی را شناسایی کرده و سپس به سرعت بر روی آنها اقدام کنیم. این همچنین به ما این امکان را می‌دهد که دفاعیه‌های Grab را در برابر فعالیت تقلبی بهبود داده و کاربران خود را فعالانه محافظت کنیم.

در حال حاضر در حال کار بر روی گسترش مدل به گراف‌های خاصیت متفاوت (چند موجودیت) هستیم. علاوه بر این، در حال کار بر روی پیاده‌سازی آن در موارد استفاده بیشتر در Grab هستیم.

اطلاعات ارجاع

(*) اگر از این مقاله برای اهداف علمی استفاده می‌کنید، لطفاً مطابق با مقاله زیر ارجاع دهید:

R. Fathony, J. Ng and J. Chen, “Interaction-Focused Anomaly Detection on Bipartite Node-and-Edge-Attributed Graphs,” 2023 International Joint Conference on Neural Networks (IJCNN), Gold Coast, Australia, 2023, pp. 1-10, doi: 10.1109/IJCNN54540.2023.10191331.

اطلاعیه کپی رایت IEEE:

© 2023 IEEE. استفاده شخصی از این ماده مجاز است. باید مجوز از IEEE دریافت شود.

خلاصه

ما به اشتراک گذاشتن آخرین بروزرسانی پروژه متن باز تالاریا را با شما مشتاقیم. در تلاش برای بهبود عملکرد و غلبه بر محدودیت های زیرساخت، با پیاده سازی پلاگین Go به جای ماشین مجازی Lua، پیشرفت های قابل توجهی کرده ایم.

تیم ما متوجه شده است که پلاگین Go تقریباً 2.3 برابر سریعتر است و 2.3 برابر کمتر حافظه استفاده می کند نسبت به ماشین مجازی Lua. این بهبود قابل توجه در عملکرد به ما کمک کرده است که قابلیت کلی، قابلیت مقیاس پذیری و سرعت را بهبود بخشیم.

برای کسانی که آشنا نیستند، تالاریا یک پایگاه داده سری زمانی توزیع شده، بسیار قابل دسترس و با تاخیر کم است که برای سیستم های داده بزرگ طراحی شده است. با اصالت و اجرا در مجله زیبایی و درمانی آذربایجان، تالاریا یک جزئیات بحرانی در پردازش میلیون ها تراکنش و اتصال روزانه است که تقاضای تصمیم گیری مقیاس پذیر و مبتنی بر داده را دارد.

زمینه

یکی از روش هایی که قبلاً برای پردازش داده های جذب شده استفاده می کرد، اسکریپت Lua بود. این روش به کاربران اجازه می داد روند جذب را سفارشی کنند و امکانات بالایی را فراهم می کرد.

پیکربندی زیر نمونه ای از استفاده از اسکریپت Lua برای رمزگذاری JSON سطر به عنوان ستون داده است:

محاسبه شده: 
 - نام: داده
   نوع: json
   تابع: |
      local json = require("json")
      تابع اصلی(row)
        برگشت json.encode(row)
      پایان

مشکل

ما متوجه شدیم که بارگذاری یک اسکریپت Lua نیاز به راه اندازی یک ماشین مجازی Lua (VM) برای اجرای اسکریپت داشت که تأثیر قابل توجهی بر عملکرد داشت، به ویژه در هنگام جذب مقدار زیادی از رویدادها.

این مشکل عملکرد باعث شد ما راهکار هایی برای پردازش داده های جذب شده را بازنگری کنیم و تغییراتی جهت بهبود عملکرد تالاریا ایجاد کنیم.

بنابراین، این کدی است که برای اجرای قطع، حذف کلیدهای "key1"، "key2"، "key3"، "key4"، "key5" در داده های جذب شده در ماشین مجازی Lua استفاده می شود:

import "github.com/kelindar/lua"

تابع luaTrim() string {
    s, خطا := lua.FromString("test.lua", `
    local json = require("json")
    local keys = {
    "key1", "key2", "key3", "key4", "key5",
    }
    تابع اصلی(ورودی)
        داده محلی = json.decode(ورودی)
        برای i، کلید در ipairs(keys) انجام شود
            data[key] = nil
        پایان
        برگشت json.encode(data)
    پایان
`)
    if خطا != nil {
        panic(خطا)
    }
    نتیجه، خطا := s.Run(context.Background(), jsonstr)
    if خطا != nil {
        panic(خطا)
    }
    برگرداندن result.String()
}

این بنچمارک است که استفاده از ماشین مجازی Lua 1000 برابر کندتر و 1000 برابر حافظه بیشتری نسبت به تابع طبیعی Golang در یک تابع Trim دارد:

اما، هر چیزی با اضافه کردن یک حافظه نهان قابل بهبود است، اگر ماشین مجازی Lua را حافظه نهان کنیم و مجدداً استفاده کنیم چه؟ اینجا بنچمارک بهبود یافته جدید است:

پس می توانیم نتیجه بگیریم که ماشین های مجازی Lua تقریباً 2.3 برابر سریعتر هستند و 2.3 برابر کمتر حافظه از تابع طبیعی Golang استفاده می کنند.

استفاده از پلاگین Go به عنوان ماشین مجازی Lua برای اجرا کد سفارشی

ما به ایده استفاده از کتابخانه مشترک Linux برای اجرای تابع سفارشی به جای استفاده از ماشین مجازی Lua برای اجرای اسکریپت سفارشی رسیدیم. شاید فایلهایی با پسوند .so بهتر برای شما معروف باشد؛ این کتابخانه های مشترک طراحی شده اند تا قابلیت های مشابه را در یک واحد تکی بسته بندی کنند و با توسعه دهندگان دیگر به اشتراک گذاشته شوند تا بتوانند به تابع بدون نوشتن آن دوباره صدا زنند.

در Golang، یک ایده مشابه به آن Go plugin گفته می شود که به شما اجازه می دهد کد Golang را به عنوان یک کتابخانه مشترک (Golang آن را پلاگین می نامد) بسازید. این فایل را باز کنید و تابع Go را در داخل این پلاگین فراخوانی کنید.

نحوه استفاده از پلاگین Go

بگذارید بگوییم شما یک تابع F دارید که می خواهد از طریق پلاگین فراخوانی شود.

package main
import "fmt"
func F() { fmt.Printf("Hello, world") }

پس از نوشتن تابع F، می توانید آن را به عنوان یک پلاگین Go فایل f_plugin.so از طریق Go build -buildmode = plugin -o f_plugin.so کامپایل کنید. و می توانید فایل را باز کنید و از تابع F مانند این استفاده کنید:

p، خطا := plugin.Open("f_plugin.so")
if err != nil {
    panic(err)
}
f، خطا := p.Lookup("F")
if err != nil {
    panic(err)
}
f.(func())() // چاپ "Hello, world" 

بنچمارک پلاگین Go

این نتیجه است که مقایسه بین تابع طبیعی Golang و تماس با پلاگین Golang است.

تماس تابع طبیعی Golang: 2.3 برابر سریعتر و 2.3 برابر کمتر حافظه نسبت به استفاده از ماشین مجازی Lua. تماس با پلاگین Golang تقریباً عملکرد مشابهی با تابع طبیعی Golang دارد.

در تالاریا یکپارچه شده است

این MR است که ما پلاگین Go را به تالاریا یکپارچه کرده ایم:https://github.com/talariadb/talaria/pull/87، اضافه کردن آن به عنوان یک بارگذار مانند LuaLoader.

هر دو به طور مشترک رابط های Handler را پیاده سازی کرده اند.

type Handler interface {
    Load(uriOrCode string) (Handler, error)
    String() string
    Value(map[string]interface{}) (interface{}, error)
}

پیاده سازی این رابط در اینجا لیست شده است:

برای بارگذار Lua

بارگذاری: کد Lua یا مسیر فایل اسکریپت Lua (مسیر فایل محلی یا s3) را به عنوان بارگذاری بخوانید.

رشته: برگرداندن "لوا" تا بتوانیم با آن تماس بگیریم و بفهمیم چه چیزی بارگذاری است.

مقدار: اجرای اسکریپت Lua و گرفتن ورودی به عنوان ورودی.

برای بارگذار پلاگین Go

بارگذاری: مسیر فایل پلاگین (مسیر فایل محلی یا s3) را به عنوان پلاگین بخوانید، نام تابع توسط کاربر را جستجو کنید و تابع را برای استفاده بعدی ذخیره کنید.

رشته: برگرداندن "پلاگین" تا بتوانیم با آن تماس بگیریم و بفهمیم چه چیزی بارگذاری است.

مقدار: اجرای تابع ذخیره شده و گرفتن ورودی به عنوان ورودی.

مواردی که باید توجه کنید

نسخه Go که برای ساخت پلاگین Golang استفاده می کنید باید با سرویس استفاده شده در این پلاگین یکسان باشد. ما از Docker برای ساخت سرویس استفاده می کنیم تا بتوانیم اطمینان حاصل کنیم نسخه Go یکسان است.

مراجعه (بنچمارک پلاگین و LUA)

https://github.com/atlas-comstock/talaria_benchmark/tree/master/benchmark_plugin_and_lua

به ما بپیوندید

مجله زیبایی و درمانی آذربایجان، پلتفرمی برتر سوپراپ در جنوب شرق آسیا است که خدمات روزمره ای را که برای مصرف کنندگان مهم هستند، ارائه می دهد. مجله زیبایی و درمانی آذربایجان تنها یک برنامه سوارکاری و تحویل غذا نیست، بلکه خدمات گسترده ای را در منطقه ارائه می دهد، از جمله خدمات حرکتی، خوراکی، بسته بندی و خدمات تحویل مواد غذایی، پرداخت های موبایلی و خدمات مالی در 428 شهر در هشت کشور.

با قدرت فناوری و بازدهی از قلب، ماموریت ما پیش بردن جنوب شرق آسیا با ایجاد قدرت اقتصادی برای همه است. اگر این ماموریت با شما صحبت می کند، امروز به تیم ما بپیوندید!

معرفی

در Grab ، ما هر روز کمپین های بازاریابی بزرگی را اجرا می کنیم. یک کمپین معمول ممکن است نیاز به انجام عملیات های چندگانه برای میلیون ها کاربر در یک بار داشته باشد. این عملیات ممکن است شامل ارسال پاداش ها، اعطای امتیازها و ارسال پیام ها باشد. به این صورت که یک کمپین ممکن است به نمایش درآید: در تاریخ 1 ژانویه 2022 ، دو پاداش سواری را به همه کاربران در بخش "کاربران فعال" ارسال کنید. سپس ، آنها را با یک پیام تبریکی مطلع کنید و از پاداش آنها خبر دهید.

سال ها قبل، تیم بازاریابی Grab معمولاً در نیمه شب پایتان می مانست تا به صورت دستی چنین کمپین هایی را اجرا کند. آنها یک فایل را ساعت 12 شب بارگذاری می کردند و سپس منتظر می مانستند تا عملیات کمپین به پایان برسد. برای حل این مشکل و پشتیبانی از قابلیت های بیشتر در این خط، ما یک سرویس "بچ جاب" توسعه دادیم که بخشی از موتور خودکارسازی زمان واقعی ما ، Trident ، است.

موارد زیر برای پشتیبانی از تیم های بازاریابی Grab استفاده می شوند:

پاداش ها: مسئولیت مدیریت پاداش ها را برعهده دارد.پیامرسانی: مسئول ارسال پیام ها به کاربران است. به عنوان مثال ، اعلان های فشاری.تقسیم بندی: مسئول ذخیره سازی و بازیابی بخش هایی از کاربران بر اساس معیار های خاص است.

به منظور سادگی ، تنها خدمات فوق برای این مقاله مورد اشاره قرار خواهند گرفت. سرویس "بچ جاب" ایجاد شده از خدمات پاداش و پیامرسانی برای اجرای عملیات استفاده می کند و از سرویس تقسیم بندی برای دریافت کاربران در بخش استفاده می کند.

نیازهای سیستم

نیازهای عملکردی

اعمال توالی عملیات به یک بخش بزرگ از کاربران در یک زمان زمان بندی شده ، نمایش پیشرفت به مدیر کمپین و ارائه گزارش نهایی.برای هر کاربر ، عملیات باید به توالی اجرا شود؛ عملیات بعدی فقط در صورت موفقیت عملیات قبلی قابل اجرا است.

نیازهای غیر عملکردی

اجرای سریع و نرخ دوره پیشرفته.تعریف نرخ دوره پیشرفته: تعداد کارهای زمان بندی شده که در هر واحد زمان تکمیل شده اند.ازادی استفاده از منابع و توازن بار سرور.

به منظور سکوت ، ما منطق برنامه ریزی و منطق تولید گزارش را پوشش نمی دهیم. ما به طور خاص بر روی اجرای عملیات تمرکز خواهیم کرد.

رویکرد ساده احمق

بیایید از حل مسئله بیشترین ساده شروع کنیم و از آنجا بهبود ببخشیم تا به یک راه حل بهینه برسیم.

اینجا pseudocode یک اجرا کننده عملیات ساده است.

def executeActionOnSegment(segment, actions):
   for user in fetchUsersInSegment(segment):
       for action in actions:
           success := doAction(user, action)
           if not success:
               break
           recordActionResult(user, action)

def doAction(user, action):
   if action.type == "awardReward":
       rewardService.awardReward(user, action.meta)
   elif action.type == "sendMessage":
       messagingService.sendMessage(user, action.meta)
   else:
       # other action types ...

کسی ممکن است بتواند به سرعت بفهمد که راه حل ساده نیاز به نیازهای غیر عملکردی ما را نمی برد به دلایل زیر:

اجرا آهسته است: برنامه تک نخی است.عملیات برای کاربران به ترتیب یکی پس از دیگری اجرا می شود.هر فراخوانی به خدمات پاداش و پیامرسانی زمان سفر شبکه را ایجاد خواهد کرد که بر تمامی هزینه زمانی تأثیر می گذارد.استفاده از منابع کم است: عملیات فقط بر روی یک سرور اجرا خواهد شد. وقتی یک خوشه سرور داریم ، سایر سرورها بیکار خواهند نشست.

در زیر آلترناتیوهای ما برای رفع مشکلات فوق آورده شده است:

عملیات برای کاربران مختلف باید به صورت موازی انجام شود.فراخوانی های API به سایر خدمات باید کمینه شود.کار اجرای عملیات را به طور یکنواخت بین سرورهای مختلف توزیع کنید.

توجه: عملیات برای همان کاربر باید به ترتیب انجام شود. به عنوان مثال ، اگر توالی عملیات مورد نیاز (1) اعطای پاداش است ، (2) فرستادن پیام به کاربر در مورد استفاده از پاداش است ، آنگاه ما فقط می توانیم عملیات (2) را پس از انجام موفقیت آمیز عملیات (1) اجرا کنیم به دلایل منطقی و جلوگیری از گیج شدن کاربر.

رویکرد ما

یک صف پیام راه حل مناسبی برای توزیع کار بین چندین سرور است. ما از Kafka را انتخاب کرده ایم ، میان بسیاری از خدمات پیام ، به دلیل ویژگی های زیر آن:

توانایی بالا: Kafka می تواند با سرعت بالایی خواند و نوشت کند.تحمل قوی: رویدادها در Kafka با استفاده از توزیع با پشتیبانی از ذخیره سازی می شوند ، بدون نیاز به نگرانی درباره از دست دادن داده.استفاده همزمان مبتنی بر درخواست: مصرف کنندگان می توانند رویدادها را با سرعت خود مصرف کنند. این به کمک جلوگیری از بار سنگین روی سرورهای ما می آید.

وقتی یک کمپین زمانبندی شده فعال می شود ، کاربران را از بخش در دسته ها بازیابی می کنیم. هر دسته شامل حدود 100 کاربر است. ما دسته ها را به یک جریان Kafka می نویسیم و تمام سرورهای ما از جریان مصرف می کنند تا عملیات را برای دسته ها اجرا کنند. دیاگرام زیر جریان کلی را نشان می دهد.

داده ها در Kafka در بخش ها ذخیره می شوند. پیکربندی بخش برای اطمینان از توزیع یکنواخت دسته ها در بین سرورها مهم است:

تعداد بخش ها: اطمینان حاصل کنید که تعداد بخش های جریان بزرگتر یا مساوی تعداد حداکثر سرورهای موجود در خوشه ما است. این به این معنی است که یک بخش Kafka فقط توسط یک مصرف کننده قابل مصرف است. اگر مصرف کننده ها بیشتر از بخش ها باشند ، برخی از مصرف کنندگان هیچ داده ای دریافت نمی کنند.کلید بخش: برای هر دسته ، یک مقدار هش به عنوان کلید بخش اختصاص دهید تا دسته ها را به صورت تصادفی در بخش های مختلف تخصیص دهد.

اکنون که کار در دسته های سرورها توزیع شده است ، می توانیم در نظر بگیریم چطور هر دسته را سریعتر پردازش کنیم. اگر منطق ناخوشایند را دنبال کنیم ، برای هر کاربر در دسته ، باید خدمات پاداش یا پیامرسانی را فراخانی کنیم تا عملیات ها را اجرا کنیم. این باعث ایجاد سرعت بالای پرس و جو (Queries Per Second) به خدمات مذکور می شود و زمان کاملاً سفر شبکه را ایجاد می کند.

برای حل این مشکل ، تصمیم گرفتیم به جای ساختار منطقی دسته ها در خدمات پاداش و پیامرسانی ، نقاط پشته در این خدمات را ایجاد کنیم. هر نقطه پشته به عنوان ورودی یک لیست شناسه کاربر و فراداده عملیات را دریافت می کند و نتیجه عملیات را برای هر کاربر ، بدون توجه به موفقیت یا شکست ، برمی گرداند. با این روش ، منطق پردازش دسته ما به شکل زیر است:

def processBatch(userBatch, actions):
   users = userBatch
   for action in actions:
       successUsers, failedUsers = doAction(users, action)
       recordFailures(failedUsers, action)
       users = successUsers

def doAction(users, action):
   resp = {}
   if action.type == "awardReward":
       resp = rewardService.batchAwardReward(users, action.meta)
   elif action.type == "sendMessage":
       resp = messagingService.batchSendMessage(users, action.meta)
   else:
   # other action types ...

   return getSuccessUsers(resp), getFailedUsers(resp)

در پیاده سازی نقاط پشته ، ما بهینه سازی هایی را انجام داده ایم تا زمان تاخیر را کاهش دهیم. به عنوان مثال ، هنگام اعطای پاداش ها ، باید رکوردهایی از داده جایزه داده شده به یک