System Design / Arkitektur Best Approach

stemmer
1

Jeg har et system, som har 3 generelle deler for å hjelpe min beskrivelse.

1) DATABASE - for å lagre alle tabeller, den samme databasen vil lagre data for andre tjenester i tillegg inkludert en webapplikasjon, Silverlight osv ... (Må være fleksibel, hvis på en ekstern server, kan bli utsatt via en web-tjeneste, hvis lokalt, kan koble lokalt eller via TCP til windows Service)

2) BLACK BOX - prosess ett element om gangen, ved å injisere i listen av nødvendige elementer fra databasen, for eksempel et rør, hvor u satt i et sett av betingelser, verdier for et enkelt element, og returnerer resultatet fra den enkelte behandlet punkt.

3) WINDOWS SERVICE - å hente data fra databasen, injiserer inn i den svarte boksen, lagrer resultatene fra sort boks til databasen ved forhåndsdefinerte intervaller. Tjenesten kan bli sittende på en annen server til databasen. Logger feilen og fortsette bør en feil oppstår.

I gjennomsnitt, vil Windows Service må behandle ca 5000 gjenstander, og det vil ta den svarte boksen på 1,5 sekund til å behandle 5000 elementer.

Mitt spørsmål er:

a) Dersom vinduene tjenesten får en batch liste over elementer for å behandle fra databasen, eller bør den få en liste over IDer, og i en sløyfe få den enkelte elementer fra databasen før du passerer videre til den svarte boksen? Legg merke til at den samme databasen som brukes av andre programmer også. Forsøksvis, jeg gjetter databasen bør være en web-tjeneste samtale av noe slag.

b) Dersom en enkelt sak lagres umiddelbart etter behandling? Eller bør det vente for batch er ferdig før du lagrer? Som sparer hver enkelt sak etter behandling er god når systemene plutselig svikter midt i prosessen, minst bearbeidet de er frelst, men på bekostning av ytelsen på grunn av sin 5000 samtaler til web-tjeneste?

Noen råd på en optimal løsning?

Jubel

Publisert på 30/12/2009 klokken 00:02
kilden bruker
På andre språk...                            


2 svar

stemmer
1

MSMQ er Microsofts kø tilnærming. Jeg er enig i en kø tilnærming bør brukes - dette gjøres i de fleste systemer som håndterer store antall transaksjoner. For eksempel i banken Jeg pleide å workfor vi brukte MQ som vår mellomvare løsning.

Fordelen er at det neste trinnet i forarbeide kan begynne umiddelbart behandle etter den første, uten å vente på alle 5000 oppføringer som skal behandles. Hva om tallet øker til 500 millioner? Så ventetiden for det første elementet for å fullføre vil gå opp enormt. Ved hjelp av en kø tilnærming, ville det ikke endre det hele tatt.

Det er andre fordeler - skalerbarhet, robusthet, ting som garantert levering - men du kan lære om disse spørsmålene senere.

Også produserer en godt gjennomført køen svært lite vente overhead i prosessene som bruker det, siden de nesten alltid støtte flere tråder tilgang køene. (Det vil være overhead, men det vil ikke en kraftig økt ventetid).

Svarte 30/12/2009 kl. 00:27
kilden bruker

stemmer
2

  1. du bør trekke elementene i en batch slik at du ikke tette nettverket med forespørsler. gripe en liste over IDer, så looping dem og trekke fulle element hver gang er N ekstra databasekall.

    • du kan bruke en webservice å håndtere kalle databasen, hvis du tror du vil ha nytte av abstraksjon. ellers vil du bare lage unødvendig kompleksitet.

  2. oppdatere vår database som du er ferdig med hvert element. de ferdige elementene kan brukes lenger ned linjen så snart de er klare, i stedet for å måtte vente på grupper av 5000 for å fullføre.

    • Dette forutsetter at du skal lagre data for hvert element

    • du trenger for å lage N samtaler (for å spare hvert element) uansett hva, slik at du ikke får mye ved å vente og deretter oppdatere ved slutten av hvert parti.

    • hvis det krasjer, vil du miste alle ulagrede data.

    • hvis du ikke trenger å lagre per element resultatene fra den svarte boksen så du vil ha en god grunn til å vurdere å oppdatere alt som en gruppe.


Jeg har skrevet en haug med programmer som dette for en bank. Min vanlige tilnærmingen er så follows-- Det er enkelt, feiltolerant og effektiv. (forutsatt at du trenger å behandle sett av elementer og lagre data for hver enkelt)

  1. databasen har en tabell som representerer status for behandling av et element, i tillegg til elementtabellen. for litt ekstra arbeid på forhånd, vil dette gjøre debugging og revisjon prosessen til en lek:

    table ItemsProcessStatus  -- feel free to improve upon the name
    int orderID (auto increment)
    int itemID  (fk to items)
    datetime pulledForProcessing null
    datetime finishedProcessing null
    ..etc
    
  2. Windows-tjeneste kjører på en tidtaker, si en gang hvert X minutt og trekker limit(Y)elementer for å behandle. Dette markerer pulledForProcessingflagg med et tidsstempel i ItemsProcessStatustabellen.

    • Du ønsker å trekke elementer der trakk dato er null [og også de som har blitt trukket, men ikke fullført, og er eldre enn Zmin (Jeg pleier å plukke 15 til 30 minutter)]

    • Vær forsiktig med prosedyren som trekker disse. du må bruke låser

    • Du kan avgrense dette videre: På den første iterasjon, grip Yelementer, der Yer en anstendig gjette på hvor mye du kan behandle i det tidsrommet. Den neste iterasjon, kan du beregne hastigheten som det er processesing (som en glidende gjennomsnitt) og juster antall elementer å trekke. denne måten vil det kontinuerlig justere seg til å behandle på full kapasitet.

  3. Windows Service behandler disse en etter en (vel, vanligvis er det multithreaded, så mange på en gang) ved å sende dem til den svarte boksen.

    • Jeg sette dem i en THREADSAFE kø <> (må ikke forveksles med MSMQ). Arbeideren tråder sløyfe, trekke fra køen, behandler elementet i den svarte boksen, og deretter oppdatere databasen.

    • du kan bruke noen av de typiske multithreading teknikker her (vent / puls, leser / skriver låse slank, vent håndtak), eller bare har arbeideren tråden sove i noen sekunder hvis køen er tom

  4. Etter hvert punkt utførelser, ring oppdateringene proc for dette elementet, som også oppdaterer ItemsProcessStatus tabellen (som angir at den er ferdigbehandlet)

  5. Når tjenesten er stoppet, ferdig med å behandle noen produkter som blir behandlet og oppdatere dem i db.

    • For alle ting som aldri har blitt sendt til den svarte boksen, fjerne merkingen du dem i prosessen tabellen ved å sette pulledForProcessingtil null.

  6. Hvis tjenesten krasjer, trenger du ikke 'miste' en masse data. elementer som ikke fikk umerket vil bli trukket igjen når de er over en viss alder (prosesstabellen)


Dette fungerer med flere forekomster av Windows Service installert på en rekke servere (selv om du ønsker å legge ComputerNametil prosessen bordet for å identifisere hvilken datamaskin hver tjeneste kjører på). Dette fungerer fordi hver tjeneste bare griper 'neste settet med elementer' til prosessen - det er ikke behov for noen form for ruting eller for de prosesser for å kommunisere med hverandre.

Svarte 30/12/2009 kl. 01:19
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more