Transcrições
1. Boas-vindas a este curso!: Olá pessoal e bem-vindos
a este curso sobre a preparação para a entrevista de design
do sistema. Meu nome é Alex e sou engenheiro
de software, o teste que está sendo feito
e também dando entrevistas de
System Design durante meu tempo em empresas de software. Quando ouvi falar
da possibilidade de criar um curso para explicar mais sobre essas
entrevistas complexas, o tipo II estava bastante ansioso para desenvolver um. Esta aula será estruturada em quatro lições que contêm etapas
práticas para você tomar para entender exatamente o que os
entrevistadores
esperarão ao
agendar esses tipos de entrevista que você
irá evoluir primeiro, apresentar a você qual é o design
do sistema. E então veremos o
modelo que funciona quando se
trata de resolver qualquer pergunta de entrevista de
design do sistema. Depois disso,
também resolveremos duas
das perguntas de entrevista mais comuns desse campo, projetando um novo URL, reduzindo o serviço e
o sistema de compartilhamento de fotos. Se você estiver interessado
em melhorar suas habilidades de
entrevista com engenheiro de software, considere este curso para você. Não há outros
requisitos, em seguida, uma conexão com
a
Internet S para o projeto desta classe, será extremamente
prático e
envolverá você a seguir as etapas apresentadas no modelo do
curso. Assim, você pode começar sua jornada de resolver questões de
entrevista de design do sistema. Pensamos no dito, acho que estamos prontos. Vejo você na primeira lição.
2. O que é design de sistemas?: Olá pessoal e bem-vindos de
volta ao sistema. Você contou a ele um tutorial
entrevistado. Nesta palestra, vamos discutir o que exatamente
é o design do sistema, o que é suposto ser uma entrevista de design de
sistema. Também vamos
dar uma olhada em algumas boas
práticas gerais quando
se trata de sua própria entrevista de
design de sistema. Você pode estar colocando-os para uma
posição em que você está
tentando conseguir um emprego para uma empresa de
engenharia de software. E você ouviu os dois, eu vou ter uma entrevista de
design de sistema junto com as entrevistas mais
orientadas técnicas onde você realmente
deveria revestir. Bem, em geral, em entrevistas de design
do sistema, você não tem
permissão para revestir. Talvez apenas um pouco para provar seus pontos em algumas partes. Agora, começar
com a definição do que exatamente o sistema
projetou a facilidade. É apenas o
processo de definir diferentes módulos,
interfaces, componentes e também os dados de
um sistema para atender aos requisitos
especificados
que podem ser especificados em sua pergunta que você
obtém um mais recente na entrevista. Agora, o processo de
desenvolvimento do sistema é na verdade, o processo
que você vai fazer no seu trabalho. Se você conseguir a posição de
desenvolvedor, onde você realmente
criará ou alterou o sistema. Junto com os processos,
modelos, metodologias e também práticas que
são usadas para desenvolvê-los. Mas, por enquanto, o design do sistema é apenas o processo
de definição dos componentes. Então, basicamente, está falando
sobre o que seria necessário ao tentar
pensar em desenvolver um
projeto do zero. Chegando à entrevista à parte esta
entrevista de design do sistema que, novamente, você pode ter conduzido com o único propósito de permitir os candidatos que
estão tomando. Como talvez programadores,
mas também podem ser engenheiros ou designers. A oportunidade de provar sua experiência no campo ao
qual eles estão se candidatando. A aplicação tangível
do conhecimento na solução de um problema real que
a empresa pode estar enfrentando. Então, esses são novamente, problemas
muito grandes e
gerais também. Então você
será solicitado a implementar algo como um
bate-papo do WhatsApp ou algo assim. teremos exemplos Também teremos exemplos concretos
mais adiante neste curso. Mas, novamente, eles são
grandes problemas e você precisa falar
sobre eles e pensar como você
os implementaria de forma otimizada do ponto de vista da
complexidade do tempo e do espaço. Agora, essa entrevista de
design do sistema
também é realizada posteriormente
no processo de entrevista. Primeiro de tudo, você pode estar recebendo uma
entrevista técnica onde você é realmente solicitado a
codificar um problema real. E, mais tarde, no processo de
entrevista, apenas para DC, você tem conhecimento prévio
de alguns tópicos e também é capaz de ver as coisas
de uma perspectiva maior. Eles também vão
lhe dar a entrevista de design do sistema. Agora, este teste pretendia que seja ver o quão bem
você trabalha em uma equipe. E também você está se
aproximando de uma
solução de problemas usando
perguntas que são, como mencionei
anteriormente, abertas. E você só precisa
chegar à melhor solução
possível. Esta entrevista
deve analisar seu processamento,
resolver os problemas, seu processo de pensamento na
criação e também projetar os sistemas para ajudar
eventuais clientes que firmam que você
deseja entrar necessidades. Também é uma oportunidade para você mostrar
ao pessoal de contratação, seja o gerente
ou outros desenvolvedores quais você está fazendo
essa entrevista. Os dois são valiosos para o membro, exibindo suas
habilidades dessa maneira. Quando se trata de perguntas de
entrevista e respostas no design do sistema, elas geralmente são
muito ambíguas. E isso é apenas para permitir a oportunidade de demonstrar
suas qualificações. Mas você não precisa se
apressar em dar uma resposta que possa estar
errada ou nem mesmo errada, mas não suficientemente documentada. Você também se reúne para fazer
perguntas antes responder à pergunta deles apenas para
restringir o escopo. Dê uma direção a você para
esclarecer também as explicações. Isso foi sobre isso para uma apresentação geral de
uma entrevista de design do sistema. Na próxima palestra,
vamos discutir um pouco como podemos abordar todas as questões de
entrevista de design do sistema. Há um
processo de quatro etapas que foi documentado
para estar funcionando, circulando para dar uma
olhada nisso também. Mas, por enquanto, muito
obrigado por ficar comigo até
o final desta palestra. E estou ansioso para ver
vocês no próximo.
3. O modelo para qualquer pergunta: Olá pessoal e bem-vindos de volta
ao tutorial de
entrevista de design do sistema. Nesta palestra,
vamos dar uma olhada em alguns passos que podemos usar em um modelo quando recebermos uma pergunta de design
do sistema
em uma entrevista. Este temporário o tempo prestes
a falar é um tamanho
único para todos os tipos de
modelo quando
se trata de perguntas de
entrevista de design do sistema, há apenas alguns passos que você precisa para garantir que você passa ao responder à pergunta da
entrevista de design do sistema. Então, começando
com esse modelo, a primeira coisa que
você precisa ser compartilhado ao fazer a pergunta é que você o entende completamente. Então, precisamos entender
esse problema. Eles precisam que você
resolva e estabeleça o escopo do design sobre o qual
você vai falar. Esta é a parte em que
você precisa fazer perguntas logo após t fornecer os detalhes completos
sobre as perguntas. E você também
precisará estabelecer quaisquer restrições
que possam aparecer. Você não precisa se apressar em tentar resolver o
problema antes de ter todos os fatos e ter
outras coisas que podem
não estar claras para você
esclarecidas pelo entrevistador. O próximo passo seria
propor um design de alto nível. Eu digo que você
não precisa
entrar na implementação
sem confirmá-lo. A abordagem em que você
está pensando é realmente satisfazer todas
as restrições que eles querem. Portanto, você pode propor uma
abordagem que você acha que é a melhor para resolver
o problema de design do sistema. Veja como eles reagem à sua abordagem antes
de entrar na
implementação de fato onde até mesmo
entrando em detalhes em cada parte
da sua proposta. Agora, a terceira parte
é realmente feita mais demorada do modo, que é o design Deep Dive. Isso acontece depois que
você validou com seu entrevistador que você está no
caminho certo, você sabe neste
momento, você
só precisa entrar em todos os detalhes
do aplicativo resolvendo que você inventou. E esta é a parte em
que você precisa ter profundo entendimento e
vocabulário do design de sistemas. E neste projeto de mergulho profundo, há muitos passos novamente e começam a mergulhar fundo. A primeira pergunta que você
precisa fazer são os requisitos. E os requisitos podem ser funcionais ou não funcionais. Os requisitos funcionais
são apenas funcionalidades que o problema que você
está resolvendo está fornecendo aos usuários. Por exemplo, em
suas mídias sociais, há uma funcionalidade
que você pode gostar de uma postagem de
qualquer outro usuário. Esse é um requisito
que é funcional. Você precisa estabelecer
e percorrer todos os
requisitos funcionais com seus entrevistadores por curso, listá-los e validar
sua importância. Agora, os requisitos
também podem ser não funcionais, e aqui podem estar algumas
coisas como a latência, que é o
tempo de resposta da interação do usuário. Confiabilidade, o que significa que não
haverá perda de dados. A consistência, o
que significa alta disponibilidade. Agora, duas coisas que você
também precisa ter em mente ao tentar projetar seus componentes. Você
precisa fazê-los. Em primeiro lugar, tolerante a falhas, o que significa que seu sistema está
funcionando em todos os momentos, mesmo que
possa haver alguns erros
ou algum risco de banco de dados. E eles também precisam
ser doenças escaláveis. Outro fato importante, escalável significa apenas
que você precisa lidar com a crescente quantidade de
tráfego em seu sistema. Indo. Além disso, para a segunda
parte deste projeto Deep Dive. Além dos requisitos,
você também precisa fazer
uma estimativa de armazenamento com
base na modalidade de dados, você precisa apenas fornecer
uma estimativa aproximada da quantidade de dados que devem ser armazenados. Além disso, você precisa pensar sobre
o número de solicitações, o serviço que você fornece
e a taxa de leitura. Depois de falar sobre todas essas estimativas
de armazenamento, você precisa pensar em
um design de banco de dados. Aqui, as ações
que você é usuário pode executar para interagir com
seu sistema estão ocorrendo. Você também pode pensar aqui sobre qual tipo de
banco de dados você
usará e também por que
você pode ir para SQL, NoSQL e assim por diante. Você só precisa discutir
sobre cada opção e pensar em qual delas se encaixa melhor
na sua solução. Em seguida, uma
quarta etapa seria iniciar o design básico de
alto nível, onde você pode escrever
sobre os clientes,
os servidores e
também o banco de dados. E a partir
desse projeto básico, você também pode obter mais detalhes e
isolar os serviços, particionar os dados
falados sobre cache e também a replicação dos
serviços e bancos de dados, até mesmo balanceamento de carga
e filas de mensagens. Se isso se adequar ao seu problema
específico. É claro que existem opcionais sobre algumas outras
coisas que você pode pensar, dependendo exatamente do problema
que você recebe, que pode ser a criptografia de algumas mensagens ou senhas. Alguma telemetria que
garante que você
acompanhe as coisas que mais
se usam em seu
aplicativo. Detecção de
serviços de gateway de API e também d serviço de análise que analisa as solicitações
e o beta do usuário. E depois deste projeto
de mergulho profundo, o último passo, você precisa dar isso
para apenas terminar, que
significa que, com o
projeto dado, para construir. Se parecer sensato, você pode pensar em identificar alguns gargalos e áreas de
melhoria e falar um pouco sobre eles. Essa é a
estrutura geral que você precisa ter em mente antes iniciar sua entrevista de
design do sistema sem sequer
receber o problema. Em algumas palestras futuras, vamos dar uma olhada em perguntas
específicas da
entrevista de design do sistema como projetar o
pequeno sistema de URL, mecanismos de
busca, unidades compartilhadas e assim por diante você celular posso ver como eu aplico todas essas etapas
a partir desse modelo exato, minha abordagem ao
resolver problemas de DC. Se isso soa
interessante para você, estou ansioso para vê-lo
nas próximas palestras. Muito obrigado
por ficar
comigo até o final deste.
4. O serviço de encurtamento de URL: Olá pessoal e bem-vindos de volta
ao tutorial de
entrevista de design do sistema. Nesta palestra,
vamos discutir o famoso problema que muitas vezes é dado nesses tipos
de entrevistas. E, mais especificamente, o projeto de um novo serviço de
encurtamento de URL. Assim como por exemplo, você pode ter visto um pequeno
URL ponto L e assim por diante. Nesta palestra, vou analisar todos os
aspectos que você precisa considerar ao usar este tópico em uma entrevista de
design de sistema. E depois de assistir a esta palestra, você saberá como
seguir essa pergunta. Mas não só isso, você também saberia como você pode abordar estudos de
problemas semelhantes. Porque ao resolver esse problema, também
respeitaremos
o modelo que devemos usar em qualquer pergunta de design de
entrevista do sistema que nos seja dada. Começando com esse problema de
entrevista, precisamos projetar, como eu disse, um
serviço de encurtamento de URL, como URL minúsculo. E esta superfície
fornecerá, é claro, lise
curta,
direcionamento vermelho URLs muito longos. Agora, a dificuldade
da entrevista de design do sistema
é bastante básica e muitas vezes
é a mais dada
na entrevista de design do sistema. Portanto, é muito importante que você saiba como
resolver esse problema. A primeira coisa que
precisamos discutir é por que precisamos
encurtar o URL? Aqui estão vários motivos
e por que precisaríamos disso. Em primeiro lugar, eles economizam
muito espaço quando exibidos, preveem mensagens e assim por diante. E também se você quiser
digitá-los do seu próprio teclado, você está menos propenso a
cometer erros ao digitá-los. Ele também é usado para
otimizar os links entre dispositivos e medir
o desempenho em anúncios. A segunda coisa que
precisamos abordar são os requisitos
e as metas do nosso sistema que
precisamos projetar. Quando dada essa pergunta, lembro aqui que quando você
está em uma pergunta de
entrevista de design do sistema, bem
como outros
tipos de entrevistas. E você está sendo
questionado. Você precisa esclarecer todos os requisitos
no início. Antes de tentar
responder ao seu problema. Você precisa fazer a pergunta
chamada para encontrar
o escopo exato do sistema que você é
entrevistador tem em mente, indo para as
funcionalidades que essa pequena superfície de URL deve
fornecer aos usuários finais de serviço. Nós os dividimos nas duas principais categorias
de requisitos, que são funcionais
e não funcionais. Ao pensar sobre os requisitos
funcionais, podemos pensar em dar um URL ao nosso serviço e
poder gerar de volta
um menor e único. E isso é chamado
de link curto. Esse link que nosso serviço
fornece também deve ser curto o suficiente para ser
facilmente copiado e colá-lo. E vamos discutir
mais tarde o que
significa curto o suficiente e também
concordamos com esse termo. Agora, o segundo
requisito funcional pode ser que o usuário possa
escolher um personalizado em breve
para suas URLs. Então, se eles não querem um gerado aleatoriamente
pela nossa superfície, eles também devem ser
capazes de escolher um deles. Esses links que
nossa superfície fornece também
devem ter um intervalo de
tempo após a morte. Eles devem ser excluídos
e também expiram. Porque, de outra forma, nosso
banco de dados transbordaria em algum momento se você continuar
tendo esses links nele. Por fim, os usuários acessam um
link curto devem naturalmente, ler direcionado para o link original que o link
curto representa. Há também alguns requisitos
não funcionais para o serviço de encurtamento de URL, que seria que a direção
vermelha deveria acontecer em tempo real
sem latência alguma. Porque imagine que você
gostaria de clicar em um link L-Y de ponto e
levará uma eternidade para carregar. Você era um
link real que
deseja acessar que
não seria bom. E também irritante. Além disso, outros
requisitos não funcionais seriam que o link
encurtado fornecido
não deve ser adivinhável ou previsível por um usuário eventual
malicioso. Os últimos e mais importantes requisitos
não funcionais. Seria que nosso sistema, nosso serviço deve
estar altamente disponível. Porque se estivesse inativo, todo o redirecionamento de URL
é que ele
conduziria seria,
claro, com ele. Alguns
requisitos adicionais aqui não
podem ser que nosso serviço
esteja acessível às APIs. Assim, terceiros podem fazer uma solicitação
real para
nossos endpoints e obter o URL encurtado como
resposta se
a solicitação estiver correta. Também algumas análises que
poderemos fazer
com esse limoeiro. E eles devem se preocupar com
quantas vezes a Ressurreição aconteceu e também Quanto mais
frequentemente onde a direção se liga, acesso e coisas assim. Depois de discutirmos todos
esses requisitos e custos do sistema, podemos passar para o terceiro, que é a estimativa
da capacidade que o serviço deve ter e
também a restrição de vencer. Então, quando pensarmos sobre o serviço que
implementaremos, é claro que ele será lido pesado. Isso ocorre porque muitas
solicitações de direção
vermelha em comparação com o novo encurtamento de URL
estarão disponíveis. E podemos assumir aproximadamente 90 para uma proporção
entre leitura e gravação. Porque se você pensar sobre isso, você só gera o link uma vez, mas é claro que seria
lido muito mais de uma vez. Agora, as estimativas de tráfego
para o serviço, podemos supor
que teremos acima 100 ou 500 milhões de novos
encurtamentos de URL por mês
criados. Então 500 milhões de URLS
talvez sejam serviços de torre. Com nossa porcentagem de readwrite, podemos esperar cerca de 50
bilhões de ereções vermelhas durante este mês. Também podemos pensar em
consultas por segundo para o
nosso sistema apenas para
impedir que nosso banco de dados seja
visto de falhar. Mas, além disso, também
precisamos analisar
as estimativas de armazenamento. Aqui podemos novamente fazer estimativas. Suponha que armazenemos todas as
solicitações de encurtamento de URL por cinco anos. Como temos 500 milhões de
novos URLs e
objetos B e D que esperamos armazenar serão
cerca de 30 bilhões. E assumindo que eles levaram cerca de
400 a 500 bytes cada, precisaremos de
aproximadamente 15 terabytes para armazenar todos os nossos dados. Também precisamos pensar
nas estimativas de largura de banda, não apenas na
estimativa de armazenamento correta, podemos esperar cerca de 200 a
300 novas URLs a cada segundo. E isso é, claro, um top. Vamos olhar para
o topo dessa gama. Portanto, o total de dados recebidos
para o nosso serviço seria cerca de 500 bytes por solicitação vezes dois ou 300 novos
URLs e B segundo,
portanto, cerca de 100 a 200
kilobytes por segundo. Uma solicitação de leitura. Já que a cada segundo esperamos cerca de 20 a 30
mil URL já direções, o total de dados de
saída será de cerca de dez
megabytes por segundo. Também podemos analisar
alguma estimativa de memória. E se quisermos
pegar alguns dos nossos URLs curtos mais usados
que são muito SH disse x. Bem, podemos olhar um
pouco para a regra 8020. Isso está dizendo que os 20% dos nossos URLs
gerarão 80% do tráfego. Portanto, 20% dos nossos URLs curtos
gerados serão os mais quentes. E no curto olhar, podemos ver que, se tivermos 20 a 30 mil
solicitações por segundo, obteremos cerca de 1,7 a 8 bilhões de solicitações por dia. Para capturar 20% desses, vamos
precisar de aproximadamente 170 gigabytes de memória. Como você viu na minha abordagem, a parte da
estimativa de capacidade e restrições precisam ser muito simples,
pensando no limite e estimar quanta
capacidade real e largura de banda ele vai ser tomado
pela superfície implementada. Eu disse que também podemos ver algumas APIs e discutir essa parte. Podemos disponibilizar alguns endpoints que nosso
serviço
fornecerá a terceiros que queriam acessar nossa exibição de serviço, fazer solicitações aos nossos
endpoints e voltar como um responda ao URL encurtado. Por exemplo, podemos ter um endpoint que o leste
chamou de criar o URL. E ele pode usar o
URL original como um parâmetro de string, que é claro o URL original que você
deseja ter encurtado. E também algum tipo
de chave
associada à chave do
desenvolvedor da API de uma conta. Então, sabemos quem está
fazendo essas solicitações e temos algum tipo de
segurança nessas partes. Como eu disse antes, esse endpoint, é claro que
retornaríamos
a inserção bem-sucedida. É claro que
retornaria uma string com o URL encurtado se
a solicitação for feita. Bem, e se não, talvez um código de erro, também
podemos ter um endpoint de URL de
exclusão. O que isso é importante, você também pode
mencioná-lo de qualquer forma. Também precisamos pensar em
como evitar abusos aqui. Se expormos uma API porque um usuário mal-intencionado poderia
colocá-lo fora do negócio e destruir seus serviços
se ele colocar algum URL de oliva t é o design atual e
preencher seu banco de dados. Podemos impor aqui algum limite
à chave do desenvolvedor da API. Ele pode ser limitado a um certo
número de criações de URL que dizem dez ou 20 dias
ou algo assim. Agora, o próximo passo
seria pensar sobre o
design e o esquema do banco de dados. Definir o esquema nos estágios iniciais
da entrevista
realmente ajudaria você a entender o fluxo entre os componentes, guiaria você para o
particionamento posterior dos dados. Agora, algumas observações
aqui seriam que
precisamos armazenar para os
serviços bilhões de registros. Vamos ter
muitos URL encurtados. Mas esses objetos
serão muito pequenos, como eu disse, 500 kilobytes. Não há relacionamentos
entre os registros. Então, além de armazenar quais
usuários criaram esse URL, você é praticamente livre para
fazer o que quisermos aqui. E outra observação sobre
o design do banco de dados e relevante aqui é
que nosso serviço será muito pesado
na parte vermelha. Vamos precisar, como eu disse, duas tabelas, uma para armazenar as informações
sobre os mapeamentos de URL e outra para os dados do usuário, que criou o link curto. Desde que antecipamos
armazenar muitas linhas. E também não precisamos manter nenhum relacionamento
entre objetos. Agora, o tipo de
escolha SQL seria muito bom aqui, pois
também é muito fácil de dimensionar. Assim, podemos olhar para
algo como o Dynamo DB. Eu vim aqui enquanto você resolve, precisamos criar o esquema de banco de dados em uma
entrevista e também pensar que tipo de banco de dados
deve ser usado e também sugerir um de
seu próprio conhecimento. O sexto passo aqui
será o design e
o algoritmo básicos do sistema. Então, aqui vamos realmente
entrar
na implementação de como nosso serviço
funcionará nos bastidores. O problema que estamos resolvendo
aqui é gerar
a chave exclusiva abreviada que será mapeada para um determinado SIC de URL
maior e maior. Nesta situação,
temos duas abordagens. Podemos gerar essas chaves de linha com um serviço de
geração de chaves. E vai gerar cadeias
aleatórias de seis letras antemão e
armazená-las em um novo banco de dados. Sempre que quisermos
encurtar o URL aqui, podemos pegar um que
já é gerado pela
superfície e anuncia. Essa abordagem é muito
simples e rápida, mas como
não estamos codificando o URL, então não precisamos nos
preocupar com duplicações ou conluições. O serviço da
geração de chaves garantirá que todas
as chaves serão únicas. Também precisamos ter em
mente alguns
problemas de simultaneidade aqui, porque
assim que uma chave for usada, ela deve ser marcada em nosso
banco de dados para garantir que ela não seja usada novamente. E se houver
vários servidores que estão lendo essas
chaves simultaneamente, você pode ter um cenário em que dois ou mais serviços
tentaram ler do banco de dados, mesmo que de cima
para o serviço endpoints, seria muito menos provável. Agora, os servidores podem usar esses sistemas de geração para ler e letreiros em um banco de dados. E eles podem usar duas
mesas para armazenar as chaves. Uma para as chaves reais
que ainda não foram usadas e outra para as chaves
que já foram usadas. E assim que esse serviço de geração
fornecer a chave para um
dos servidores, coma e mova para a mesa. Precisamos também
pensar aqui, se nosso sistema de geração, sendo o sistema único
de todo o nosso serviço, não
seria ruim
se ele morresse? E esse é um ponto muito bom porque precisamos ter
uma réplica em espera, esse sistema de geração
para ter um servidor em espera que possa assumir o controle para
gerá-los, forneça fácil no caso de algo acontece
com um primário. Agora, outra abordagem aqui, outra degeneração
morta das chaves com o serviço. Também é codificar a codificação de URL
real. Um URL real pode ser feito
calculando um hash exclusivo. Se estivermos
falando sobre o tiro 250 assentos ou os cinco vazios, e podemos hash o
URL fornecido com esses algoritmos, esses hashes podem ser
codificados para exibição. E uma pergunta
razoável nessa abordagem seria qual seria o tamanho
da chave abreviada? Pode ter seis até
20 caracteres pares, mas isso seria uma chave
bastante longa. Podemos usar a codificação base 64. E se vamos
usar teclas longas de seis letras, então levará cerca de 64 para a potência de
seis cordas possíveis. Se gerássemos teclas longas de
oito letras, teremos cerca de 280
trilhões de cadeias de caracteres possíveis. Mas para o nosso sistema, o número da letra
seria bastante alto. E podemos supor que
seis letras podem ser suficientes para o nosso número de URLs. Agora, se usarmos o algoritmo MD5
como nossa função hash, ele fornecerá, como você já deve saber, valores de hash de
128 bits. Após a codificação base-64,
obteremos uma string com
mais de 21 caracteres. Agora só temos espaço para seis ou oito caracteres
por tecla curta. Como vamos escolher nossa chave então? Bem, podemos pegar
as primeiras letras, mas isso pode resultar
em duplicação de chaves. E para resolver isso,
podemos optar colocar alguns outros caracteres fora
da codificação ou
trocar entre eles para evitar
esse problema completamente. Também podemos, depois de dar a
solução em uma entrevista, pensar em alguns problemas
com a nossa solução, é que pode
não ser à prova de balas e esses diferentes problemas vêm de você e
não o entrevistador. Você provavelmente
ganhará pontos extras à medida que se torna um eventual funcionário mais
consciente. Os diferentes tecidos
com a codificação de um URL real
usando uma hashtag. Uma solução única pode ser que, se vários usuários
inserirem o mesmo URL, eles podem obter o
mesmo URL encurtado. Os problemas de simultaneidade
é que foi o caso B, a última abordagem também. Mas aqui está outro. E se partes do
URL, URL codificadas? As soluções alternativas aqui novamente, acrescentando um número de
sequência crescente a cada URL de entrada para torná-lo
único e gerar seu hash. E outra solução pode
ser anexar o ID do usuário, que deve ser exclusivo
ao URL de entrada. Se o usuário não
tiver entrado aqui, pode ser um problema
porque precisaríamos
disso para confirmar a
singularidade da chave. Mesmo que depois de todos
esses passos que
tomamos para garantir que nada
cresça poderia acontecer, ainda
temos um conflito. Podemos continuar gerando a chave até
conseguirmos a única. Encerrando o
projeto básico do sistema uma parte do algoritmo. A segunda parte aqui
seria o
particionamento de dados e a
replicação de nosso serviço. Para dimensionar nosso banco de dados, precisamos particioná-lo para que ele
possa armazenar mais informações. Precisamos de cerca de bilhões de
entradas em nosso banco de dados. E aqui podemos dar uma olhada nos dois tipos de
particionamento que existem,
que são a chave inglesa e o particionamento baseado em hash. Começando com os URLs do
portal de fins de semana de
particionamento
baseado em intervalo URLs do
portal de fins de semana de
particionamento
baseado em em partições
separadas com base nas chaves de hash, caracteres ou até mesmo em uma delas. Assim, podemos salvar todos os
URLs começando, por exemplo, trigo ou letra a
em uma partição, e salvando os
que começam com a letra B em outra
, e assim por diante. E olhando em contraste com o particionamento baseado
em hash neste esquema, podemos pegar o hash
do objeto
que estamos
armazenando e, em seguida, calcular com base naquela partição usar. No nosso caso, podemos pegar
o hash da chave ou o encurtamento para
determinar a partição que vamos
iniciar esse URL específico. A próxima coisa que
precisamos pensar ao abordar o
problema de design do sistema é a parte do dinheiro. Assim, podemos capturar URLs
acessadas com frequência , como já
sugerimos anteriormente. E podemos usar qualquer solução de
prateleira que existe lá fora pelo
memcached, por exemplo. Mas também podemos armazenar URLs completos. E, ao fazer isso,
armazene o URL completo doce seus respectivos hashes em seu surfista de
dedicação. Nessa abordagem,
antes que você possa pensar, o armazenamento back-end
pode verificar rapidamente se o cache já possui
o URL de design. E assim,
um serviço mais ideal. Também precisamos
pensar aqui em quanta memória cache
devemos ter. Para que possamos começar. Cerca de 20% do tráfego diário e com base nos padrões de uso do
cliente, ajuste além disso,
quantos casos de servidores precisamos. Conforme estimado acima, precisamos cerca de 170 gigabytes de memória
para lucrar 20% do tráfego. Como um
serviço moderno pode ter 256 gigabytes de memória, pode facilmente encaixar todo o
dinheiro em uma máquina. Isso foi sobre isso com
a parte de armazenamento em cache. Também podemos pensar sobre o balanceador de
carga em nosso sistema, o que é bastante simples. Podemos pensar em adicionar
essa camada de balanceamento de carga em três lugares. E esses seriam entre os clientes e os servidores de
aplicativos,
e também entre servidores de
aplicativos
e servidores de banco de dados
e servidores de cache. Passar para a coisa de
dança que precisamos
pensar quando esses sistemas projetam a pergunta de
entrevista dada a nós é a limpeza ou a
limpeza do banco de dados. A entrada
não deve ficar por aqui para sempre em nosso banco de dados, pois ela a preencheria e transbordaria
causando uma falha. Epoch. Existe um tempo de
expiração especificado é atingido? O que deve acontecer com o link? Bem,
se optássemos por
procurar continuamente experimentos
para removê-los, isso colocaria muita pressão
em nosso banco de dados também. Então, em vez disso, podemos remover lentamente os links expirados
fazendo uma limpeza preguiçosa. E a forma como nosso
serviço garantirá que apenas os links expirados serão excluídos com B sempre que o usuário tentar
acessar o link inspirado, excluímos o código de
entrada para o usuário. Dessa forma, não excluir
todas as URLs expiraram de uma só vez e
arriscando uma falha no banco de dados. Também podemos ter um tempo de
expiração padrão para cada link no que diz respeito a
esse aspecto. Por fim, também precisamos ter
em mente que a árvore limite, que deve responder a
algumas perguntas pois quantas vezes o URL
curto foi usado. Qual era a localização do usuário? Qual seria a data e a
hora do acesso e assim por diante. Parte de segurança e permissões, que é outra importante. Podemos armazenar o nível de
permissão com cada URL no banco de dados
sendo público ou privado. Para os privados, também
podemos criar uma
tabela separada para armazenar IDs de usuário que têm permissões para
ver esse URL específico. É claro que, se não
tiver essa permissão, nosso endpoint ou x está
no URL curto, pode retornar um HTTP
para um código, o que significa eixo insuficiente. Claro. Isso foi acima todos os ângulos que você
precisa ter em mente ao abordar uma solução para
a questão de
superfície de URL de encurtamento em uma revisão de projeto do sistema. Espero que vocês tenham realmente tirado
algo dessa palestra. E eu agradeço muito por ficar comigo
até o final. Também estou ansioso para ver
vocês no próximo.
5. O aplicativo de compartilhamento de fotos: Olá pessoal e
bem-vindos de volta ao tutorial de
entrevista de design do sistema onde
entendemos como podemos passar por uma entrevista composta por perguntas de sinal
C3b. Nesta palestra,
vamos discutir outro problema muito comum
que é dado esses tipos de entrevistas
e dar uma olhada em exatamente como podemos
resolvê-los para passar, como eu disse, a entrevista. O problema que não
vamos analisar
nesta palestra é projetar
um serviço de compartilhamento de fotos. Aqui, os usuários podem fazer upload fotos para compartilhá-las
com outros usuários. E, claro, alguns serviços
semelhantes podem ser Flickr ou algumas plataformas de
mídia social, mesmo que tenham mais funcionalidades
integradas nelas. Em primeiro lugar, ao
abordar esse problema, vou usar o
modelo geral que é ajustado para qualquer questão de design do sistema
que possa ser dada em uma entrevista
sobre a qual falei em uma palestra anterior. E o primeiro passo depois entender
completamente
a pergunta e fazer qualquer outro
aplicativo de consulta que você possa ter de seu entrevistador é
definir os requisitos
e os objetivos do o sistema sobre o qual você
vai falar. Ao projetar nosso aplicativo de
compartilhamento de fotos, gostaríamos de ter alguns requisitos
funcionais que incluem que um usuário possa seguir alguns outros usuários que têm
uma conta nesta plataforma. O usuário também pode
realizar algumas pesquisas que podem ser baseadas nas
fotos compartilhadas. Você pesquisou também pode fazer upload
de fotos da conta deles. E o sistema que
implementaremos também deve gerar e exibir algum tipo de feed de
notícias onde um usuário, quando abrir
o aplicativo, verá as melhores fotos
das pessoas que ele lutou contra arcos. Estes são, como eu disse, os requisitos
funcionais, mas também precisamos pensar
sobre os funcionais. O
requisito não funcional número um precisa ser que o sistema
seja muito confiável, que
significa que, uma vez que o
usuário enviar uma foto em nossa superfície, a foto não será perdida. Em seguida, nossa superfície
precisa estar altamente disponível,
portanto, qualquer dúvida não é permitida. Além disso, devemos manter nossa latência baixa para a regeneração de notícias
e coisas assim. Ou seja, a quantidade de
tempo que o usuário realmente
aguardará de iniciar o aplicativo até
o ponto em que ele
realmente verá algumas fotos de outros usuários que ele segue. Então, agora o primeiro passo está pronto. E definimos os
requisitos e
os objetivos do sistema
que estamos prestes a projetar. Podemos fazer algumas outras considerações de
design. Aqui. Podemos começar pelo fato de que todo esse serviço que
vamos implementar, é bastante óbvio que
será muito lido pesado porque a dívida líquida quando os usuários realmente
enviarão fotos, mas um
número muito maior de usuários na verdade, verá as fotos
que outros usuários viram. Você pode pensar nisso, como
pensaria ao postar uma fotografia em seu aplicativo de mídia
social. Você publica muito poucas vezes, mas você realmente vê muitos outros recursos em comparação para ver você realmente carregar. É por isso que esse sistema
será lido pesado. Pelo fato de que nosso
serviço será lido pesado, precisamos nos concentrar em recuperar. A foto é muito rápida. Agora, os usuários podem carregar tantas fotos
quanto a luz do dia também. Então isso é uma coisa a ter
em mente porque precisamos um gerenciamento muito eficiente do armazenamento para essas fotos. E também, salvo disse, se um usuário enviar uma foto, esse sistema que projetamos, garantimos que ela não
será perdida. Passar para algumas
estimativas e restrições para a capacidade das coisas que
vamos armazená-lo. Podemos supor que
teremos 100 milhões
de usuários com
cerca de 10 mil usuários ativos
diários e 2 milhões de novas
fotos todos os dias. Seriam cerca de 23
novas fotos a cada segundo. E esses cálculos
que vamos fazer aqui ocorrem em uma data adicional, onde
nosso serviço
será altamente adotado
e bem-sucedido. Então é por isso que você me
vê quebrar esses
valores muito altos para estes. Números reais. Agora, o espaço total necessário para um dia de
fotos, como eu disse, seria de cerca de 2
milhões porque
dissemos que teríamos 2
milhões de novas fotos todos os dias. E podemos pensar sobre o tamanho
médio do arquivo de fotos, que pode ser de 100 kilobytes, que será cerca de 200 gigabytes no
total para nossa capacidade. Agora isso só está levando
em conta um dia. Mas e se apontarmos
o espaço por, digamos, cinco anos? Bem, podemos multiplicar
200 por 3655 anos, e vamos obter
cerca de 365, então 365 terabytes. Agora que temos essa
estimativa de capacidade fora do caminho, podemos pensar no design do sistema de
alto nível. Porque em um nível alto só
precisamos suportar dois cenários. Um para carregar as fotos, que é fluxo de trabalho
em nosso serviço. E sim, eles queriam
ver ou pesquisar essas fotos. O serviço que
vamos implementar, é
claro, precisa armazenar
as fotos em algum banco de dados. E vamos precisar alguns
servidores de armazenamento de objetos aqui. Além disso, para o esquema de banco de dados
para armazenar essas fotos, ele também será
discutido na entrevista. Precisamos ter em mente que temos cerca de três entidades. Um que
será o usuário, em seguida,
as fotos e, em seguida, os
usuários que eles seguem. O esquema pode estar
contendo três tabelas. Quando uma foto, que
pode ter um ID com foto, que
será a chave primária. E, em seguida, alguns outros
campos, como o ID do usuário, que é claro
que o
usuário morto o publicou, o que será uma chave
estrangeira nesta tabela. Então, um
outro campo muito importante aqui
será a data de criação, que será
do tipo datetime. E este é um
campo muito importante porque vai ser útil quando o usuário
abrir seu feed de notícias, queríamos dar-lhe as fotos mais recentes
e populares, mas para a última
parte vamos ser útil quando o usuário
abrir seu feed de notícias,
queríamos dar-lhe as fotos mais recentes
e populares,
mas para a última
parte vamos
comer esse campo de batida região. Em seguida, também temos
a tabela de usuários, que obviamente terá
uma chave primária de ID de usuário. E então alguns outros dados que
queríamos armazenar para ele. Se quisermos fazer e-mail
marketing pode manter seu e-mail. Mas também precisamos do
nome, da data de nascimento, da data de cada conta e talvez do último login. Estou pensando. Também precisaríamos de uma tabela
para o usuário seguir, que tomaria um campo que fará parte
da chave primária. E isso será, é claro, IDs de
usuário dos usuários
que se seguem. Portanto, isso, é claro,
leva em consideração o cenário em que
o usuário de acompanhamento vai para
os dois lados, como no Facebook quando
você adiciona um amigo. Então, se vocês aceitarem vocês dois
como amigos, não como um Instagram onde o seguimento pode ser
unidirecional. Então você pode seguir alguém
que não o seguiria. Não temos esse cenário
nesta discussão apenas para que
possamos torná-lo um
pouco mais simples. Agora, a
abordagem direta para invadir os
detectores de esquemas
falam seria um MySQL exigir
obviamente as articulações, mas podemos armazená-lo em uma loja de valor chave
distribuída para aproveitar o benefícios
oferecidos pelo NoSQL também. Depois de falarmos sobre o
esquema do banco de dados em nossa entrevista, também
precisamos fazer outra
estimativa do tamanho dos dados. Portanto, o D decide estimativa
sobre o contém informações sobre os campos que serão armazenados
em nosso banco de dados. E precisamos pensar
sobre os números inteiros, cadeias de caracteres e assim por diante. Mais tarde, será
armazenado em nosso banco de dados. Podemos supor que cada
consulta de entrada e o DateTime
passaram quatro bytes. Portanto, cada linha na
tabela de usuários terá cerca de 68 bytes. Se tivesse, como eu contei anteriormente,
cerca de seis campos. Se tivéssemos, digamos, 250 milhões de usuários, precisaremos de cerca de 16
gigabytes de armazenamento somente para a parte do usuário possa
ser armazenada com todas as suas informações
em nosso banco de dados. Mas e com as fotos? Então, cada linha na tabela de
fotos terá cerca de 284 bytes Cs. Também temos um pacote de fotos, que será var chart até 265 caracteres
e que leva 265, assista a
entrada da foto que
seria bastante
maior do que a do usuário, mas isso seria bem normal. Se levarmos em conta cerca de 1 milhão de novas fotos
sendo enviadas todos os dias, precisaremos de cerca de 200 e 50 megabytes de
armazenamento por um dia. E isso vai
ser em dez anos, cerca de um terabyte, quase. A última tabela, cada usuário segue
a tabela. E se
consistir em oito bytes, tínhamos apenas a chave primária
composta por duas integrais, que são cada quatro bytes. Podemos pensar em cerca de
250 milhões de usuários. Eles podem seguir outros 250 milhões de usuários
e vamos
encontrar outros petabytes adicionais de armazenamento para a tabela seguida
do usuário. O espaço total necessário para todas essas tabelas para os ouvidos, como eu disse, seria de
cerca de dois terabytes, o que é realmente
ótimo para uma aplicação. E a superfície desses tipos. No próximo fim de semana, também analisou
rapidamente o design dos componentes
que teremos neste serviço. A foto carrega ou fica
bem devagar. Leia quem será mais rápido, especialmente se eles estiverem
sendo atendidos em dinheiro. Fazendo upload, os usuários podem consumir conexões
de
deck disponíveis porque o upload
é um processo lento e isso significa que não
podemos ser atendidos. Qualquer sistema fica ocupado com
todas as solicitações certas. Devemos ter em mente que esses serviços da Web têm uma conexão se nos encontrarmos
antes de projetar o sistema. Portanto, se você assumir que
um servidor da Web pode ter um máximo de 500
conexões em n vez, então ele pode ter mais de
500 uploads simultâneos ou leituras manipuladas com
esse gargalo, podemos dividir leituras e grava
em serviços separados. Isso também nos permitirá
no futuro escalar essas operações de
forma independente e muito mais fácil, pois são
duas entidades separadas. Para a parte de redundância agora, perder arquivos é que
mencionei anteriormente, não
é uma opção. Podemos iniciar várias cópias de cada arquivo como solução para dívidas. Porque se um dado de armazenamento, podemos recuperar o quarto
muito forte, a outra cópia. Mas o mesmo princípio também
se aplica a outros componentes. Então, se quisermos ter a
disponibilidade do sistema que seria de alta venda,
nosso sistema não
estaria morrendo em nenhum momento. Também precisamos ter replicações
do serviço em execução. Os serviços diminuíram. O sistema permanece
disponível assustador, pois essa redundância remove
o ponto único de falha no sistema. Esse é um ponto muito importante. Ao fazer qualquer entrevista de
design do sistema, você precisa pensar que se você está implementando está
realmente fazendo um único ponto de
falha S a dívida é uma desvantagem e
precisa ser observada. E você também precisa encontrar
uma solução alternativa para isso. Se apenas uma instância
dos serviços necessária para executá-la a qualquer momento, poderemos executar uma cópia
secundária redundante
do serviço que não está
servindo nenhum tráfego, mas pode assumir o
controle após o fatal para surdos brancos
primários tem problema. Como eu disse, são duas instâncias
do mesmo serviço em
execução na produção
e uma falha. O sistema pode fazer failover
para a cópia saudável. E isso pode acontecer
automaticamente ou exigir intervenção manual, mesmo que, se você
não entrar seu sistema em
qualquer momento, é melhor implementar
e recuperar automaticamente. Porque de outra forma,
você precisaria
observar que seu
sistema é chiclete e, em seguida, intervir
manualmente com a
dívida do desenvolvedor pode, é claro, por si mesmo, redirecionar o
17º 2D disponível. Também podemos falar sobre
o compartilhamento de dados. Porque, é claro, acho que quantidades
tão altas de dados, precisamos de alguma forma compartilhá-los. Podemos traçar no ID do
usuário para que possamos manter todas as fotos de um usuário
no mesmo
banco de dados nítido e definido curto é um terabytes. Você precisaria
de quatro gráficos para armazenar cerca de quatro terabytes de dados. Agora, para o fim de semana de desempenho e escalabilidade,
mantenha cerca de dez deles. Novamente, o sistema FOR cresce
cada vez maior, seremos capazes de
lidar com todo o tráfego de dívidas. Vamos precisar encontrar o número acentuado
pelo
usuário múltiplo de dez. Vamos começar por aí. Identifique exclusivamente qualquer
foto em nosso sistema. Podemos anexar esse
número ao ID da foto, e essa seria
uma
solução bem simples a esse respeito. Como podemos gerar as
identificações de fotos enquanto cada banco de dados pode ter sua própria
sequência de incremento automático para os IDs de foto. E como vamos acrescentar essa
ideia da identificação com foto nítida, ela a tornará única
em todo o nosso sistema. Mesmo que tenhamos criado
esse sistema de particionamento, ele tem algumas desvantagens. Por exemplo, se não pudermos armazenar todas as imagens
usando demais meu gráfico, temos
que distribuí-las para várias delas e causaremos doenças
mais altas posteriores. E também os usuários do coração precisam ser tratados de
forma bastante diferente
porque são seguidos por muitos outros usuários e muitas pessoas. Eles verão o upload das fotos e a dívida
pode causar problemas
nesse sentido. É claro que podemos particionar o
ID da foto e não o ID do usuário, que pode ser outra abordagem. Porque se geralmente
esse ID de foto for o primeiro, podemos encontrar o
número nítido novamente, módulo de identificação
da foto, que significa que eles são
menos dígitos basicamente. E, claro, os problemas
acima sobre
os quais acabamos de falar eram as desvantagens após a
primeira abordagem teriam sido
resolvidos neste momento. Novamente, para gerar
os IDs de foto, você não pode ter uma sequência
de incremento automático porque você precisa saber que o ID da
foto é primeiro definir a solução nítida aqui
pode ser dedicar um banco de dados separado gerar esse ID
de incremento automático, precisamos também pensar
muito
sobre o futuro e misturar nosso
crescimento do sistema. Se tivermos um grande número
de partições lógicas para acumular o
crescimento de dados no início, várias
partições lógicas dentro um único banco de dados físico, banco de dados
CCS ou podemos ter vários
sistemas de bancos de dados em execução nele. Podemos ter
bancos de dados separados para cada partição lógica
em qualquer servidor. Sempre que achamos que um determinado
servidor de banco de dados tem muitos dados, podemos criar algumas
partições lógicas para outro servidor e podemos manter
um arquivo de configuração. E isso constituiria a
única coisa que teríamos que
atualizar para anunciar
uma eventual mudança. A geração de ranking e
feed é outro problema com o qual
enfrentamos. A maneira como vamos
lidar com isso. Ou pelo menos uma maneira de
lidar com isso é
pré-gerar o feed dos EUA. Podemos ter alguns servidores que sua única tarefa
seria gerar usuários continuamente e armazená-los em outra tabela chamada feed de notícias
do usuário. Quando o usuário precisar de barriga
esta foto para uma nova suíte, simplesmente
consultaremos esta
tabela e retornaremos os resultados. Leslie, também
precisamos pensar sobre o dinheiro e o
balanceamento de carga do sistema como ele será muito usado um,
precisamos introduzir
um cache para mim para o Serviço de
Dados para capturar as linhas
do banco de dados. Isso significa as hot
folders e os usuários. Podemos usar o
caso de demanda para casar esses dados e
servidores de aplicativos.
Antes de entrar no banco de dados,
pode verificar rapidamente se o cache tem as rotas
desejadas. Aqui, uma abordagem que seria razoável seria o R U, que é o menos usado
recentemente. Para a política de despejo de cache. Podemos construir o integrante
mais inteligente Kiersten, estes usando a regra 8020, que afirma que 280%
do volume de fotos que
serão lidas diariamente, vamos gerar 80%
do tráfego, para que possamos apenas descontar
os primeiros 20%. Então, isso era sobre todas as
etapas e dados intermináveis. Eu consideraria um impotente na
entrevista de design do sistema e
recebia uma implementação de design de
serviço de compartilhamento de fotos. Agradeço
muito a vocês por comigo até o
final desta palestra. E estou ansioso para
vê-lo no próximo.
Programming Made Easy, Software Developer
