Geekly articles weekly

Almacenar el estado del chat en la pila

¡Todo lo nuevo está bien olvidado!

Ahora, muchas personas están escribiendo varios bots que se comunican con el usuario en IM y de alguna manera ayudan al usuario a vivir.



Si observa el código de muchos bots, generalmente se reduce al mismo patrón:


  • llega el mensaje
  • se pasa al manejador de mensajes de usuario ( callback )

Esta es generalmente una forma universal de escribir bots. Es adecuado para chats de una persona y para bots conectados a grupos. Con este método, todo está bien, excepto uno: el código de incluso bots simples a menudo es bastante confuso.


Tratemos de desentrañarlo.


Comenzaré con las renuncias:


  1. Lo que se describe en este artículo es adecuado para bots del tipo <-> .
  2. El código en este artículo es un código de boceto. Escrito específicamente para este artículo en 15 minutos. Así que no juzgues estrictamente.
  3. Utilicé un enfoque similar en los negocios: con equilibrio de carga. Pero, por desgracia, mi código de producción tiene muchas dependencias de infraestructura y es muy fácil no publicarlo. Por lo tanto, este boceto se usa en el artículo. Me referiré a los problemas de desarrollo de paradigmas (describiré dónde y cómo nos desarrollamos).

Bueno, ahora vámonos.


Como soporte, considere la biblioteca asincrónica de aiograma, python3.7 + . El enlace tiene un ejemplo de un simple echo bot.


Lo copiaré aquí:


Ver código
 """ This is a echo bot. It echoes any incoming text messages. """ import logging from aiogram import Bot, Dispatcher, executor, types API_TOKEN = 'BOT TOKEN HERE' # Configure logging logging.basicConfig(level=logging.INFO) # Initialize bot and dispatcher bot = Bot(token=API_TOKEN) dp = Dispatcher(bot) @dp.message_handler(regexp='(^cat[s]?$|puss)') async def cats(message: types.Message): with open('data/cats.jpg', 'rb') as photo: ''' # Old fashioned way: await bot.send_photo( message.chat.id, photo, caption='Cats are here ', reply_to_message_id=message.message_id, ) ''' await message.reply_photo(photo, caption='Cats are here ') @dp.message_handler() async def echo(message: types.Message): # old style: # await bot.send_message(message.chat.id, message.text) await message.answer(message.text) if __name__ == '__main__': executor.start_polling(dp, skip_updates=True)

Vemos que la organización del bot es tradicional. Cada vez que un usuario nos escribe algo, se llama a una función de controlador.


¿Qué hay de malo en este paradigma?


Que la función de controlador para implementar diálogos complejos debe restaurar su estado desde algún tipo de almacenamiento en cada una de sus llamadas.


Si observa la mayoría de los bots que admiten algún tipo de negocio (por ejemplo, contratación), le hacen preguntas al usuario 1..N, luego hacen algo en función de los resultados de estas preguntas (por ejemplo, guardan el perfil en la base de datos).


Si fuera posible escribir un bot en un estilo tradicional (en lugar de un estilo de anillo), entonces sería posible almacenar los datos del usuario directamente en la pila.


Intentemos hacerlo.


Esbocé un boceto del módulo, conectando el cual puedes usar con esta biblioteca:


Ver código
 #  - chat_dispatcher.py import asyncio class ChatDispatcher: class Timeout(RuntimeError): def __init__(self, last_message): self.last_message = last_message super().__init__('timeout exceeded') def __init__(self, *, chatcb, shardcb = lambda message: message.from_user.id, inactive_timeout = 15 * 60): self.chatcb = chatcb self.shardcb = shardcb self.inactive_timeout = inactive_timeout self.chats = {} async def handle(self, message): shard = self.shardcb(message) loop = asyncio.get_event_loop() if shard not in self.chats: self.chats[shard] = { 'task': self.create_chat(loop, shard), 'messages': [], 'wait': asyncio.Event(), 'last_message': None, } self.chats[shard]['messages'].append(message) self.chats[shard]['wait'].set() def create_chat(self, loop, shard): async def _chat_wrapper(): try: await self.chatcb(self.get_message(shard)) finally: del self.chats[shard] return loop.create_task(_chat_wrapper()) def get_message(self, shard): async def _get_message(inactive_timeout=self.inactive_timeout): while True: if self.chats[shard]['messages']: last_message = self.chats[shard]['messages'].pop(0) self.chats[shard]['last_message'] = last_message return last_message try: await asyncio.wait_for(self.chats[shard]['wait'].wait(), timeout=inactive_timeout) except asyncio.TimeoutError: self.chats[shard]['wait'].set() raise self.Timeout(self.chats[shard]['last_message']) if not self.chats[shard]['messages']: self.chats[shard]['wait'].clear() return _get_message

Una pequeña explicación:


La clase ChatDispatcher se ChatDispatcher con los siguientes parámetros:


  1. funciones de fragmentación de mensajes entrantes (por qué se denomina fragmentación, más tarde, cuando tocamos cargas grandes). La función devuelve un número único que indica un diálogo. En el ejemplo, simplemente devuelve la ID de usuario.
  2. funciones que realizarán el trabajo del servicio de chat.
  3. Valor de tiempo de espera para inactividad del usuario.

Descripción del puesto:


  1. En respuesta al primer mensaje del usuario, se crea una tarea asincrónica que servirá para el diálogo. Esta tarea funcionará hasta que se complete el diálogo.
  2. Para recibir un mensaje de un usuario, lo solicitamos explícitamente. Ejemplo de chat de echo :
     async def chat(get_message): message = await get_message() await message.answer(message.text)
  3. Respondemos a los mensajes que nos ofrece la biblioteca ( message.answer ).

Intentemos escribir un bot en este paradigma


Ejemplo de código completo aquí
 #  bot.py import asyncio import re from .chat_dispatcher import ChatDispatcher import logging from aiogram import Bot, Dispatcher, executor, types API_TOKEN ='    ' logging.basicConfig(level=logging.INFO) bot = Bot(token=API_TOKEN) dp = Dispatcher(bot) async def chat(get_message): try: message = await get_message() await message.answer('  ,   ') first = await get_message() if not re.match('^\d+$', str(first.text)): await first.answer('  ,  : /start') return await first.answer('  ') second = await get_message() if not re.match('^\d+$', str(second.text)): await second.answer('  ,  : /start') return result = int(first.text) + int(second.text) await second.answer(' %s (/start - )' % result) except ChatDispatcher.Timeout as te: await te.last_message.answer('-   ,  ') await te.last_message.answer(' - /start') chat_dispatcher = ChatDispatcher(chatcb=chat, inactive_timeout=20) @dp.message_handler() async def message_handle(message: types.Message): await chat_dispatcher.handle(message) if __name__ == '__main__': executor.start_polling(dp, skip_updates=True)

Un ejemplo de bot escrito: simplemente agrega un par de números y produce un resultado.


El resultado se ve así:



Bueno, ahora echemos un vistazo más de cerca al código. Las instancias no deben plantear preguntas.


La integración con nuestro boceto se realiza en el controlador estándar al que llamamos await chat_dispatcher.handle(message) . Y describimos el chat en la función de chat , repetiré su código aquí:


 async def chat(get_message): try: message = await get_message() await message.answer('  ,   ') first = await get_message() if not re.match('^\d+$', str(first.text)): await first.answer('  ,  : /start') return await first.answer('  ') second = await get_message() if not re.match('^\d+$', str(second.text)): await second.answer('  ,  : /start') return result = int(first.text) + int(second.text) await second.answer(' %s (/start - )' % result) except ChatDispatcher.Timeout as te: await te.last_message.answer('-   ,  ') await te.last_message.answer(' - /start')

Código de servicio de chat: solo solicita los datos uno por uno al usuario. Las respuestas del usuario simplemente se apilan en la pila (variables first , second , message ).


La función get_message puede get_message una excepción si el usuario no ingresa nada durante el tiempo de espera especificado (y puede pasar el tiempo de espera en el mismo lugar).


Estado de diálogo: directamente relacionado con el número de línea dentro de esta función. Bajando el código, avanzamos a lo largo del esquema de diálogo . Hacer cambios al hilo de diálogo no es fácil, ¡pero es muy simple!
Por lo tanto, no se necesitan máquinas de estado. En este paradigma, puede escribir diálogos muy complejos y comprender que su código será mucho más simple que el código con callback .


Desventajas


Donde sin ellos.


  1. Para cada usuario activo, hay una tarea-corutina. En promedio, una CPU normalmente atiende a unos 1000 usuarios, luego comienzan los retrasos.
  2. Reiniciar todo el demonio: finaliza todos los cuadros de diálogo (y los reinicia).
  3. El código [del ejemplo] no está adaptado para la escala de carga y la internacionalización.

Si con el segundo problema está claro qué hacer: interceptar la señal de parada y decir a los usuarios "Tengo una emergencia aquí, fuego, volveré un poco más tarde". Ese último problema puede causar dificultades. Veámoslo:


Escala de carga


Obviamente, los bots cargados deben iniciarse en muchos backends a la vez. En consecuencia, se webHook modo de operación webHook .


Si solo equilibra el webHook entre, por ejemplo, dos backends, entonces obviamente debe asegurarse de alguna manera de que el mismo usuario llegue a la misma rutina que le está hablando.


Hicimos esto de la siguiente manera.


  1. En el equilibrador, analice el JSON del mensaje entrante ( message )
  2. Elija una identificación de usuario
  3. Usando el identificador, calculamos el número de back-end (== fragmento). Por ejemplo, usando el user_id % Nshards .
  4. Redirigimos la solicitud al fragmento.

ID de usuario: se convierte en la clave para fragmentar entre las rutinas de los cuadros de diálogo y la base para calcular el número de fragmento del backend en el equilibrador.


El código de dicho equilibrador es simple: está escrito en cualquier idioma en 10 minutos. No lo traeré.


Conclusión


Si escribe bots en este paradigma, simplemente puede rehacer los diálogos de uno a otro. Además, lo importante es que el nuevo programador entienda fácilmente el código de los diálogos que alguien hizo antes que él.


¿Por qué la mayoría de la gente escribe bots en la arquitectura de anillo? No lo sé.


Solían escribir en ese paradigma. Servir salas de chat en este estilo fue adoptado en la era de IRC y bots para ello. Así que no pretendo ser ningún tipo de novedad.


Y mas Si usa este paradigma en un lenguaje con el operador goto , este será solo un hermoso ejemplo del uso de goto (los bucles en los cuadros de diálogo se realizan maravillosamente en goto ). Lamentablemente, esto no se trata de Python.

Source: https://habr.com/ru/post/486006/

More articles:


All Articles