كيفية مشاركة البيانات بين عمليات بيثون دون كتابة إلى القرص

Question

Helllo، أود أن أشارك كميات صغيرة من البيانات (<1K) بين Python والعمليات. البيانات هي بيانات IO PC / 104 المادية التي تتغير بسرعة وغالبا (24 × 7 × 365). سيكون هناك "خادم" واحد يكتب البيانات والعملاء المتعددين قراءة أجزاء منه. يستخدم النظام هذا يستخدم ذاكرة فلاش (بطاقة CF) بدلا من محرك أقراص ثابت، لذلك أنا قلق بشأن ارتداء ذاكرة الفلاش بمخطط يستند إلى الملفات. أود أيضا استخدام قوة أقل (وقت المعالج) حيث نحن بالطاقة الشمسية بنسبة 100٪.

• هل هذا قلق صالح؟ ربما نغير بطاقة CF إلى SSD.
• هل تغيير قيمة باستخدام MMAP تكتب جسديا البيانات إلى القرص أو هل هذا ملف افتراضي؟
• سنكون قيد التشغيل على Debian، لذلك ربما يكون POSIX IPC لوحدة Python هو الحل الأفضل. هل استخدمه أي شخص؟
• وقد حاول أي شخص مشاركة كائن بيثون (POSH) وحدة؟ يبدو واعدا للوهلة الأولى ولكنه في "ألفا" ولا يبدو أنه يتم تطويره بنشاط.

شكرا

استكمال: تبطأنا الحد الأقصى لمعدل تحديث البيانات إلى حوالي 10 هرتز، ولكن أكثر عادة 1 هرتز. لن يتم إعلام العملاء إلا عند تغييرات القيمة بدلا من معدل التحديث المستمر. لقد ذهبنا إلى خوادم متعددة / نموذج عملاء متعددين حيث يتخصص كل خادم في نوع معين من الأداة أو الوظيفة. نظرا لأنه اتضح أن معظم البرمجة ستجري بواسطة مبرمجي Java، فقد انتهى بنا المطاف باستخدام JSON-RPC عبر TCP. سيتم كتابة الخوادم التي سيلت في جافا لكنني ما زلت آمل في كتابة العميل الرئيسي في تطبيقات Python و AM التحقيق JSON-RPC.

Answer 1

قد يكون بديلا لكتابة البيانات إلى ملف في عملية الخادم هو الكتابة مباشرة إلى عمليات العميل:

استخدم مآخذ مآخذ نطاق UNIX (أو مآخذ TCP / IP إذا تم تشغيل العملاء على آلات مختلفة) لتوصيل كل عميل بالخادم، ولديك الخادم بالكتابة في هذه المقابس. اعتمادا على نموذج المعالجة الخاص بك، قد يتم اختيار العميل / المقبس بواسطة الخادم (على سبيل المثال جولة روبن) أو من قبل العملاء يشيرون إلى أنهم جاهزون للمزيد.

Answer 2

إنشاء قسم Ramfs والكتابة إلى ذلك. (يمكنك استخدام TMPFS، ولكن على عكس TMPFS، لا يتم تبديل RAMFS في القرص). ومع ذلك، نظرا لأن RAMFS لا يحتوي على حد حجم، يجب أن تهتم أنك لا تنفد من الذاكرة؛ نظرا لأنك تكتب فحسب بت صغير من البيانات هناك، فلا ينبغي أن تكون مشكلة.

بهذه الطريقة، لن تتم كتابة بياناتك إلى قرص (ملاحظة: ستفقدها إذا فشلت الطاقة).

انظر أيضا مستندات ramfs.

Answer 3

بحسب ال مقالة ويكيبيديا حول مكالمة نظام MMAP, ، تعين الذاكرة محتويات الملفات مكتوب مرة أخرى إلى القرص عند التحديث.

هل نظرت إلى الوحدة النمطية متعددة المعالجات (في المكتبة القياسية) - وخاصة حالة مشاركة الجزء بين العمليات؟

يبدو أن Ramfs كما ذكرنا Piskvor أيضا حل جيد - خاصة عند عدم كتابة جميع العمليات في بيثون.

Answer 4

عند تشغيله على أنظمة الفلاش، تأكد من تصميم نظام الملفات الخاص بك بشكل صحيح لزيادة حياة ذاكرة الفلاش (تسوية التآكل). JFFS. وأعتقد أن الآخرين قادرون الآن على القيام بذلك بفعالية. إذا كنت تستخدم مثل هذا النظام، فلا يجب أن تشعر بالقلق للغاية حول استخدام الفلاش، ولكن بالتأكيد إذا كنت تكتب دفقا مستمرا من البيانات، فأنت تريد تجنب القيام بذلك على الفلاش.

باستخدام نظام ملفات RAM هو فكرة جيدة. الأفضل من ذلك، هو تجنب أنظمة الملفات بالكامل إذا كان تصميم النظام سيسمح لك بذلك. إلى هذه الغاية تذكرك الفاخرة. لم أحاول ذلك أبدا، لكننا وجدنا بيرو ("الكائنات البعيدة بيثون") لتكون حل أنيق وفعال في بعض الحالات المماثلة.

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